Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-91542

Provide way of supporting all Qt features on a Wayland shell

    XMLWordPrintable

    Details

    • Type: User Story
    • Status: In Progress
    • Priority: P2: Important
    • Resolution: Unresolved
    • Affects Version/s: 6.1
    • Fix Version/s: None
    • Component/s: QPA: Wayland
    • Labels:
      None

      Description

      Qt supports several windowing system features that are not supported in any of the core Wayland shells. This is often by design because things like programmatic window activation etc. is not regarded as user-friendly, in desktop environments especially.

      Leaving the question of whether there is a place for such features on desktop aside, at least in an embedded system - where Wayland is used for multi-process support but where the user interaction has very different qualities and restrictions - there is definitely a place for more control from the client side.

      The generic Wayland approach to this is to implement a new shell extension that supports the use case. But Qt makes this difficult by putting shell extension code in private, which means that normal source compatibility guarantees do not apply. End result is that the new extensions may need to be adapted when Qt is updated, adding overhead and unpredictability.

      We have identified two options for resolving this:

      1. Create a "qt-shell" which can be preferred by clients if the compositor supports them. When creating both ends of the connection, like on a typical embedded system, you will then get support for everything that Qt expects to support. The downside of this is that you may also have third-party apps that will be running on top of a different shell. This shouldn't cause conflicts, but may need additional logic in the compositor (if it e.g. relies on IVI ids to position windows). An easy mitigation would be to implement support for specific things, such as transmitting IVI ids with the new protocol.
      2. Make APIs for shell extensions public so that they can easily be extended by the user. Each user could then make their own extensions and implement the features they need.

      No decision has made yet, but currently preference is on 1, as 2 would require a lot of duplicate work for a lot of users. Since this is a quite common request, it seems like something that Qt should ideally support out of the box.

        Attachments

          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            Activity

              People

              Assignee:
              esabraha Eskil Abrahamsen Blomfeldt
              Reporter:
              esabraha Eskil Abrahamsen Blomfeldt
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:

                  Gerrit Reviews

                  There are no open Gerrit changes