xdg shell status and gaps

Jasper St. Pierre jstpierre at mecheye.net
Thu Sep 25 07:32:08 PDT 2014

On Thu, Sep 25, 2014 at 5:20 AM, Matthias Clasen <matthias.clasen at gmail.com>

> Hi,
> so yesterday we released what we described as a day-to-day usable
> GNOME/Wayland. Congratulations to everybody involved in defining
> xdg-shell on getting us this far.
> But... (I wouldn't write if there wasn't a but) we are not yet calling
> it a '100% complete port' because there are still a number of things
> that don't work, compared to X.
> It is quite possible that some of these should be done differently
> under Wayland, or not at all. It is also possible that there are
> already plans for supporting these things that I don't know about. In
> that case, please set me straight.
> Anyway, here's the list:
> 1) Marking dialogs as modal (needed so we can implement the 'attached
> modal' visuals of gnome-shell
> 2) Lowering windows (used e.g. by GtkInspector to get out of the way
> when picking a window

I'm not comfortable adding this. You can hide briefly the inspector by
giving it a 1x1 blank surface and emptying the input region. Perhaps we
should make this equivalent to what the "NULL surface" semantics are.

> 3) Raising or activating windows (needed e.g when activating a
> pre-existing window of a single-window application)

This is one of the final things that will be added to xdg_surface, as the
first revision.

> 4) Learning about output characteristics - is this display the
> 'primary' / builtin / projector ? (needed e.g. when deciding which
> output to show a presentation on)

This should be part of wl_output. I think this makes sense as a new event
on that.

> 5) Finding out if there is desktop chrome that should be avoided (ie.
> 'workarea') ? (Useful e.g. for window size heuristics)

This will be handled by the probe extension, but I'm not really sure why
you need this. You can't manually place your window with global
coordinates. "Avoiding" anything doesn't make too much sense to me.

> Outside of xdg-shell, we found that there's currently no protocol
> support for handling some traditional aspects of DND:

6) Snap-back animation if a drag ends unsuccessfully

This should be handled by the compositor, not by the app. It can keep this
surface alive and do the animation itself.

> 7) Root window drop

When is this useful?

Thanks for the list! It's always helpful to have feedback on xdg-shell.

> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140925/adda203b/attachment.html>

More information about the wayland-devel mailing list