Window stacking

Bill Spitzak spitzak at gmail.com
Fri Sep 16 13:43:27 PDT 2011


Giovanni Campagna wrote:

> I perfectly agree, and in fact, I have a wl_shell.restack as part of my
> "EMWH" branch (github.com/gcampax/wayland/desktop-shell-2). As far as I
> see it, that's all we need.

I looked at the protocol.xml and I do not like this at all.

This is copying all the mistakes of the ICCCM X11 window managers.

Clients want "this window will raise when the user clicks here in this 
other window and X and Y are true and Z is false and the phase of the 
moon is this". They do not want to look through a list of window "types" 
and guess which one does the closest to what they want, or experiment 
until they find the bug in the compositor that gives them what they 
want. You cannot communicate the information clients need unless entire 
arbitrary programs can be sent to the compositor. And this communication 
is a hundred times more complex than the simple api that lets a client 
get exactly the window stacking and positioning it wants.

In addition you seem to think the compositor can raise windows 
arbitrarily, such as on clicks. DO NOT DO THIS!!!!! Look at the history 
and you will see they realized this was wrong in X10 (they removed that 
built-in behavior). But because of Windows and a lot of idiots designing 
window managers, this crap is still reappearing. They are finally 
realizing that it makes drag & drop impossible (because it raises the 
window you drag from) and both Windows and X11 are trying to solve this 
by the horrendous approach of having to define to the window manager 
exactly what areas raise the window. Please, for the love of god, 
realize that the app can raise it's own damn windows after deciding what 
was clicked on!

The earlier design of Wayland is MUCH more like what is needed. Wayland 
is a chance to get it right, don't repeat decades of mistakes because 
you are used to it.


More information about the wayland-devel mailing list