Originally Posted by newwen
it shall be noticed that Kwin has an agenda to push with SSD's, since it implement features (such as beos-like titlebar-tabbing of windows from different applications) that actually need to be done in the server
but OTOH, it would be necessary to retains SSD's, both for compatibility with existing applications (/application that being linked to current versions of GTK and Qt -not supporting CSD- may not be binary compatible with updated libraries) and to support those generic applications not needing the ability to visually merge (something that has to be done client side) the titlebar with the menu and/or toolbars and/or MDI tabs...
Last edited by silix; 02-08-2013 at 09:06 AM.
Exactly, especially when at least with wobbly windows that visible line is an absolute corner case.
Originally Posted by Znurre
Which window manager did you develop?
Originally Posted by TemplarGR
applications can already draw their own titlebars in X if they want to (see chromium, steam, etc...) Wayland won't really change things as long as the wayland compositor is designed to sue server side decorations like kwin plans to. there will always be a few applications that are silly and try to to their own thing, but wayland isn't going to turn linux decorations into some windows-esq mess.
Originally Posted by nerdopolis
I indeed remember seeing it, but I've just tested it (KDE 4.8, I believe, whatever's in Debian) and no problems whatsoever.
Originally Posted by hiryu
BTW, I'm willing to bet my hat that now the GNOME team will do the exact opposite of this and we'll have a mess again.
SSD is not what you think
1.) with wayland Kwin is THE COMPOSITOR and THE SERVER(that Talks Wayland Protocol) and the same apply for mutter/e17/etc.
2.) SSD vs CSD is basically this:
SSD: Kwin and company allocate a Fixed set of textures in a buffer that will be composited with the application texture FBO
CSD: Kwin will allow Qt/the application to pass a texture/s that will be composited in the main application FBO
3.) Kwin and company know always where the max/min/close/titlebar/etc are no matter if CSD or SSD are used, the only question is who texturize those items before the frame get rendered Kwin or the aplication
4.) Wayland dont handle decorations(for the billion time), in the worst case wayland could only pre define a SHM/FB buffer where you can put the decoration textures in a fixed fashion that will be forced to any application FBO if not empty, just to save some calls between CPU/GPU
to be more precise (since awesomess will come trolling in soon)
* Wayland is an event driver protocol
* wayland is not a server, is just a protocol library
* Kwin/mutter/weston/etc are the ones that handle the scenarios, meaning kwin/etc will set (you dont even need texture at this point):
-- x,y position is the close operator and is waiting at a mouse/other input device event
-- x,y position is the max operator and is waiting at a mouse/other input device event
-- x,y position is the min operator and is waiting at a mouse/other input device event
-- x,y position is the others(menu/special functions) operator and is waiting at a mouse/other input device event
++ if the input device emit an event in this kwin/etc controlled region, Kwin/etc will emit a wayland input event corresponding this specific FBO(the app) and will return control to kwin/etc compositor to generate the render process(clean the framebuffer/minimize the texture/set the texture==screen size/etc).
++ if the input device emit an event in this kwin/etc controlled region but is not a wayland event(app menu/stay on top/stay below/transparency/etc) kwin/etc will pass control to kwin/etc compositor to render the event(wayland don't give a fuck about this type of events since are server specific(server == kwin and the likes) AKA CLIENT SIDE)
* the event capture is Client side (Qt/gtk/efl/etc) and server side[ish](evdev/kernel) so only kwin/etc decides if its necessary to pass a wayland event(minimize/max/close/move/etc) or a compositor event(wayland is not a compositor either Kwin/etc are)
I also don't see it in kwin. Maybe my eyes are too slow :-D
Originally Posted by hiryu
Sufficiently fast memory and an unsaturated north bridge interconnect should mean all the pages containing the decorators and window internals should be handled in <20ms. You only see the window and decorations disconnect if you are bandwidth restricted or memory access is exceedingly slow.
Originally Posted by droste
For those who are in favor of server side decorations please look at this screenshot of my desktop.
Do you really think that it wouldn't look much better if dolphin and chromium had their native decorations? What I am saying is that there will always be applications that can never ever look consistent on your desktop and most of the time they would look better if they were at least consistent in themselves.