[PATCH weston 00/10] xdg-shell unstable v5 revisited and beyond

[Jonas Ådahl]

Hi,

This emails contains two slightly disconnected parts; the first part is
regarding patch series improving the xdg-shell protocol. The second part
is regarding xdg-shell and desktop shell - client integration in general.

Part 1
======

This series is a rebase of the xdg-shell improvements made by Jasper St.
Pierre. No major changes were made to the original series; check each
patch for details about semantical changes. Trivial compile fixes etc are
not mentioned. I also bundled some cleanups, and added an extra error
error code to xdg-popup for opening with an invalid parent.

One ambiguity that I noticed (and that weston and mutter currently do
differently) that I'd like to get clarified is regarding the following
paragraph in the xdg_popup description:

      Clients will receive events for all their surfaces during this
      grab (which is an "owner-events" grab in X11 parlance). This is
      done so that users can navigate through submenus and other
      "nested" popup windows without having to dismiss the topmost
      popup.

The thing that confuse me is (except for X11 'owner-events' which I'm not
familiar with) is what this means regarding pointer/keyboard/touch focus,
and whether pointer/touch events should be sent when outside any of the
clients input regions. Should they behave as an implicit grab (i.e.
wl_pointer focus doesn't leave the surface and motion events gets
forwarded whet outside)? Should a new popup inherit the grab (i.e.
wl_pointer/wl_keyboard/wl_touch changes focus to the new popup)?

Note that this series don't tend to solve all the pending issues that
has been discussed regarding the current state of xdg-shell, and I hope we
can get these changes merged before doing further changes. As far as I can
tell the issues brought up in the previous E-mail thread of the previous
time this series was posted should have been addressed, but please do
check as I was not the one who did most of the issue addressing, and have
only checked afterwards.


Part 2
======

Even though I'd like the series talked about above to land without
stalling due to any further discussion about future xdg-shell
improvements, I'd like to provide some kind of status update / summary
of what is missing from a desktop point of view, given the comments of
previous threads on wayland-devel. It is partly based on the status
update by Matthias Clasen from last year.

1) Modal dialogs

There is currently no support for making a xdg_surface a modal dialog,
i.e. inhibiting interaction with parent surface as well as enabling the
compositor to special-case modal dialogs from regular child-surfaces.
AFAIK this could easy enough by just extending xdg_surface with an extra
request of some kind.

2) Lowering surfaces

This was meant for cases such as when the GTK+ inspector wanted the user to
choose a surface and in order to do that lower itself in order to not get
in the way. This particular use case might not be relevant, as there are
other ways to not get in the way (hiding itself with the
zero-input-region+transparent-buffer hack), or maybe using the
xdg_surface.set_parent in order to enforce stacking order. Not sure
whether hiding is enough or parent-child hack makes sense for the
mentioned use case.

3) Getting the work area

GTK+ uses this for guessing a reasonable default size for windows. The
complicated thing though is that a "work area" is dependent on what output
the surface is/will be on, and if its not already a mapped surface the
client currently won't know what output its surface will end up on. It
could be good have to avoid creating windows that are larger than the
screen though, but the above issues remains. Maybe it can be partly solved
with some kind of startup notification extension (see below)?

4) xdg-shell enforces client side decorations always

Some DEs want to have their compositor draw the window decorations of
their clients. While a Wayland client is required to always be able to
draw window decorations if it wants any, there is currently no way for the
compositor to ask kindly if the client would rather not draw them itself.
I don't know of any attempts in doing this (I have no idea how KDE does
it) or if they should be dealt with in custom protocols until we know how
they'd work.

5) No explicit support for tiling window management

While a compositor is free to place its surfaces at its own will, surfaces
might still draw shadows and what not, making it not suitable for use in a
tiling window management shell. This might be a slightly similar issue as
to 4) above, except that it maybe should be required for a surface to not
draw things outside of the window geometry (shadows etc).



There were some non-xdg-shell related missing features that were part of
the same set of discussions, which probably could need some attention now
again as well, being desktop related. So, listing them as well:

1) Output details

wl_output could still need some more data propagated to the client
(external vs internal etc). Use cases for this are presentation software
and movie players choosing the output to fullscreen their surfaces on.

2) DND improvements

The current DND protocol is limiting; there are for example no DND action
mechanism and no way to detect a failed DND, There were work[0] done to
improve the situation by Giulio Camuffo, but it seems to have stalled.

3) Startup notification

There is currently no way to connect a user action (e.g. clicking a dock
icon) and the appearance of a surface as a result of that user action.
There were a few discussions on this that brought up a dbus only based
solution, an app starter extension in combination with using
WAYLAND_SOCKET or just passing a token around. Something that a startup
notification system probably should deal with is enable launcher to
determine where new surfaces should end up. AFAIK there is no consensus
regarding what solution is preferable nor are there any prototypes I know
of.



These two lists contains the issues I could think of now but there is
probably a lot that I missed. The intention with these two lists is to
get some input and discussion going regarding the future of the desktop
shell protocols. Please share opinions, or consensus that I missed, if
there are any prototypes or intention of such for any of the issues, or
other issues that I did not mention that needs attention.


Jonas

[0] http://lists.freedesktop.org/archives/wayland-devel/2013-March/007931.html



Jasper St. Pierre (7):
  xdg-shell: Take a xdg_surface as the parent surface
  xdg-shell: Remove the serial from popup_done
  xdg-shell: Remove the flags from get_xdg_popup
  xdg-shell: Send an error when the client uses the not-topmost popup
  xdg-shell: Add a simple destructor request
  xdg-shell: Rewrite documentation
  xdg-shell: Bump unstable version

Jonas Ådahl (3):
  desktop-shell: Simplify popup_end_grab popup_done sending loop
  desktop-shell: Fix coding style of add_popup_grab
  xdg-shell: Add invalid_parent error to xdg_popup

 clients/simple-damage.c |   2 +-
 clients/simple-egl.c    |   2 +-
 clients/simple-shm.c    |   2 +-
 clients/window.c        |  21 ++--
 desktop-shell/shell.c   | 163 ++++++++++++++++++++--------
 protocol/xdg-shell.xml  | 281 +++++++++++++++++++++++++++++-------------------
 6 files changed, 301 insertions(+), 170 deletions(-)

-- 
2.1.0