client side decorations
iskren.chernev at gmail.com
Mon May 9 07:03:26 PDT 2011
I can't get one thing out of this discussion.
So you are arguing about client side VS server side decorations,
handling of moves/resizes, maybe even buttons scroll bars etc.
But all wayland does is provide a communication channel that enables
"clients" to draw in the GPU memory, and then "compositors" display
this memory the way they want to on screen.
So, in my understanding there can be compositors drawing stuff around
the windows (because they have all screen's content and they can mix
it in whatever way they want), handle common shortcuts for close, move
And there can be other compositors that don't do anything like that.
And both of these will be "wayland compositors". Or are you actually
arguing to put some additional stuff to the wl protocol that will
enable more "compositor side" actions (what is X currently doing)?
And why is everybody talking about titlebars and close buttons? I
think this is also part of the brain-damage, that years of using
windows and mac has brought us. I'm using a tiling window manager, and
I really can't understand why would anybody want titlebars & buttons
on them, unless he/she really enjoys spending half of the time moving
windows around so he can see them (if they "wobble" it is so much fun,
I agree). And how do the tiling WMs in X fit the client vs server
discussion. If it was all client side I assume no one cares about
tiling windows anymore (no application developer), so simply there
would be no tiling at all?
There are things that should be common for all windows. Like closing,
moving, resizing. Of course, because I'm using tiling window manager,
this is all done through kb shortcuts, implemented in the server (I'm
not sure if this fits the client vs server discussion, because this
does not involve drawing "decorations" but certainly puts some
overhead in the server to manage windows). I cant imagine anybody
using his computer if these operations, are done through GUI and are
done differently depending on the window. Of course this can be
"solved" outside wayland by making GTK+, Qt more alike or creating
additional communication channels between the clients and the servers.
But this then tends to another discussion we had about screen locking,
security, and vnc :) which was basically weather wl should make the
protocol handle these things, or hardcode the "strange" parts (like a
locking app) inside the compositor and use dbus or similar to link
client and server for those out-of-core-wayland issues. (The
discussion led to nowhere, as this one is also headed to).
So what are you actually arguing about :) I mean -- just both sides
explain in more detail what they want implemented where (in client, in
server, in 3rd party), because otherwise it is going nowhere.
More information about the wayland-devel