KDE/KWin On Wayland To Use Server-Side Decorations

[silix]

<snip>
Wayland compliance should enforce supporting both SSD and CSD

ditto.

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...

[Awesomeness]

First of all I find it hilarious that proper wobbly windows and rotating windows are the arguments for client side decorations.

Exactly, especially when at least with wobbly windows that visible line is an absolute corner case.

I don't see much sense from KWin's developer at all... Which is not so surprising, KWin is easily the worst part of modern KDE...

Which window manager did you develop?

[bwat47]

I think the main fear with server side decorations is it requires more inter process communication, as the server side decoration would have to be sized up against the window as it's being resized, the server would have to resize the decoration surface as well. Not only would this increase IPC,

And don't quote me on this, but I would also think that it would require the application to tell the server more about its surface, such as the window is resizable, or closable, so that the server (or separate decoration program, however it's implemented), so that it would know not to draw a close button on the decoration, or maximize button, or make the borders not re sizable.



This being said, there would have to be a protocol to tell applications not to draw their titlebars for kwin to do this...

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.

[pingufunkybeat]

That seems pretty credible, but I'm still a bit incredulous. I've never seen this personally... at least not with kwin. I've seen tons of other issues, like jerky animations and what not even with very powerful hardware, but no seams with compositing in X.

I indeed remember seeing it, but I've just tested it (KDE 4.8, I believe, whatever's in Debian) and no problems whatsoever.

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.

[jrch2k8]

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

[jrch2k8]

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)

[hiryu]

That's weird that you have not seen it before. It has ALWAYS existed in Compiz - and i have even chatted with compiz devs about it in the past (year) on launchpad (ie: it's commonly known to be the case).... and again, i highly doubt it has been fixed in Kwin - that's cool if it has, but i have my doubts...btw - did you or did you not say just one comment ago that you had also not seen it with compiz? (yet, now you're back-tracking saying "at least not with kwin" wtf? that's strange dude, kinda makes me question your 'credibility'...)

you can also doubt me / think that i am wrong all that you like, but server-side decorations seem to be problematic. I'd (almost) bet money kwin is going to have this problem in Wayland too.

also, 1st search on youtube for kde/wobbly windows shows crappy lines/gaps in kwin + wobbly windows... it's brief, but clearly visible. Start at 25sec into video watch as he moves Dolphin, then lets go of the window - you can clearly see window/decoration separation, it looks like crap. (but in using KDE, i've had it be much more obvious than this, for longer periods of time).

http://www.youtube.com/watch?v=R0xNzm4_3c0

It's been a few years since the last time I've used compiz, so it could be that I just don't remember so you very well could be right on that. I didn't mean incredulous in the sense that I literally didn't believe you, just more in the sense that I'm rather surprised that the problem exists since I've never personally witnessed it.

In regards to kwin, I use it daily and for hours on end at both work and at home, so I'm definitely not seeing it there.

[droste]

In regards to kwin, I use it daily and for hours on end at both work and at home, so I'm definitely not seeing it there.

I also don't see it in kwin. Maybe my eyes are too slow :-D

[zanny]

I also don't see it in kwin. Maybe my eyes are too slow :-D

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.

[Maxjen]

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.