[PATCH] xdg_shell: Adding a new shell protocol.

[Gregory Merchan]

On Fri, Nov 8, 2013 at 3:29 PM, Jasper St. Pierre <jstpierre at mecheye.net> wrote:
> . . .
> What's going to happen from here is that this is going to land in Weston,
> not in Wayland (I hope, at least; the subject doesn't say so!). Rafael
> Antognolli is also going to write the Weston/Westoy patches, and I'm going
> to write the GTK+/mutter support. It is going to be unstable for the time
> being. Requests and events might get added or removed, and the version
> number won't change. Your code might break for a few months while we figure
> stuff out.
>
> What I'd love to happen is for everybody (Enlightenment/EFL, GNOME/GTK+,
> KDE/Qt, and all other interested parties) to write their support for it. The
> idea here is that we have a small common base, implement that in code, and
> then once we're all done with that, we look at expanding back to around what
> the EWMH has support for.
>
> That means it's currently missing features. Support for layers like
> always-above / always-below isn't in this dump. Support for different focus
> modes isn't either. . . .

You should be aware that sophisticated focus modes have been possible
on X for almost 20 years, but they have never been implemented because
of misunderstandings, chicken-and-egg problems with window managers
and toolkits, required API changes, and probably a number of other
reasons. Wayland, left as it is now, will be only slightly better than
X in this regard; the lack of a split like between the X server and
window managers allows for better filtering of focus change requests,
however they are implemented.

Misunderstandings abound both in technical terms and in user interface
design. While the technical misunderstanding are less of a problem
since Wayland is a new system, the UI misunderstandings remain
because, unless you've used MacOS often enough in certain ways, you
don't know what you're missing. Programmers, it seems, are not the
people likely to be doing things that make these features desirable;
accordingly, they have no natural motivation to implement them.

While it will be possible to make a compositor that supports getting
focus right and toolkits that do the right thing, the chicken-and-egg
problem will remain.

When last I checked--about a year ago--the only API with support for
getting focus right was GNUstep's.

Almost 10 years ago, I filed bug reports for Gtk+ and Metacity (then
GNOME's window manager) to get this working correctly on X. I
submitted patches for Metacity and was working on the patches for Gtk+
until I had to stop for personal reasons. It had also become apparent
that, even with working code, I would have to overcome the previous 10
years of bias about how X "should" work.

I'll be quiet now.