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