KDE/KWin On Wayland To Use Server-Side Decorations

[mark45]

Each application looking different? Stupid idea.

It's not entirely true. Otherwise we should require anyone to use Gnome/Gtk because there are apps for KDE/Qt that don't look the same.
You don't need the same all the time, unless you're some old grumpy fuck or so. In society you don't need only white people. Nowhere do you need everything
to be the same, i.e. "consistent". Sometimes when the "consistent" sucks or doesn't suit your needs properly you want non-consistent.
So the idea that apps looking different must be a stupid idea - is a stupid idea.

[liam]

lol. as they say 'proof is in the pudding' ~ so i thought it was a good idea to find an example (apparently, you came to the same conclusion, eh liam?)

I did, but, embarrissingly, I wasn't able to find a video.
Well, until Google becomes sentient...

Well, again - WMs/compositors aren't (by any means) my area of expertise, sure Xorg may be the problem / the way compositors work with Xorg but from what i do understand / have read - server-side decorations seem to be the cause of a lot of ugliness / issues on the linux desktop. (but hey, if i turn out to be mistaken / misinformed - that's great too).

cheerz

I think the problem is a little bit of both. I believe OSX uses an actual window manager and they don't have these problems (that I've seen, I should add). I'm not an expert on the graphics stack but what I keep reading from the X devs is how much of the old X11 has been removed in favor extensions. Unfortunately there are some problems which would require a rewrite of X to solve. As it is they've swiss cheesed X.
There is a reason the X devs have gotten behind wayland, fellas.

[Cyber Killer]

That was exactly what I was looking for on youtube and couldn't find it. I think I may've searched for "kwin" instead of kde.
Anyway, as ninez says, around the :27s you can see a blue line appear between the menubar and titlebar in dolphin just after he stops the window movement.
That may not be kwin, however.

Use accurate scaling (instead of the default smooth) in advanced options of desktop effects in kde, then (at the cost of performance) this problem is really hard to notice, only shows with very fast wobbly window movement. You don't use low/medium detail settings in a game and then complain that it looks bad, right? It's the same here ;-).

[liam]

It's not entirely true. Otherwise we should require anyone to use Gnome/Gtk because there are apps for KDE/Qt that don't look the same.
You don't need the same all the time, unless you're some old grumpy fuck or so. In society you don't need only white people. Nowhere do you need everything
to be the same, i.e. "consistent". Sometimes when the "consistent" sucks or doesn't suit your needs properly you want non-consistent.

This is a statement that I hear voiced too infrequently.
ZDNET had an article recently (http://www.zdnet.com/android-develop...10-7000010910/) that included this quote:

There's little evidence that a top-down user experience that permeates the entire OS delivers much value to the user. This sort of approach is a solution created by platform vendors seeking a problem. (Interestingly Microsoft does this both on Windows Phone and Windows 8/Windows RT, but iOS and Android don't do this -- yet those two enjoy 95 percent market share figure?)

That surprised the hell out of me that he didn't think ios used the top-down model but the point is interesting: a completely consistent UI (although he uses the term UX, he means must mean UI) may not be much of an advantage. What matters is the UX consistency, and even that can be a bit flexible. You shouldn't mix paradigms, but you can sure as hell mix skeumorphic with functionalism (it may not look great, however) and not have a confused user base.

Use accurate scaling (instead of the default smooth) in advanced options of desktop effects in kde, then (at the cost of performance) this problem is really hard to notice, only shows with very fast wobbly window movement. You don't use low/medium detail settings in a game and then complain that it looks bad, right? It's the same here ;-).

For one, I'm not sure that would work. Also, that would be cheating
I don't think the entire point of CSD is to prevent these issues but when the X devs say this is the way to go, and I don't hear much arguing amongst them, then I think it's at least worth trying.

[TemplarGR]

Are you sure most of you know what you are talking about?

First of all most apps use a toolkit like Qt or GTK. The app doesn't need to know anything about decorations, it will be done through the toolkit instead. The toolkit could provide the means to select the decoration you want, and voila, problem solved. All KDE has to do is to provide an interface to access the toolkit settings...

For those apps that don't use a toolkit or use one that doesn't support Wayland yet, there is always the solution of using Xserver on top of Wayland to to provide compatibility... Those are very few though...

I am not sure what problem will be solved with Server-side Decorations. Decorations are simply textures added to the window of an application. What is the point of taking the texture of the window and attaching the texture of decorations when you can simply have one texture which has both? The compositor's job is simply to position those textures, nothing more...

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

[varikonniemi]

I am sure there are merits to both sides of this debate, and that the ultimate correct answer is just a matter of opinion.

Likewise, i think this Kwin developer's opinion is colored very strongly by the fact that Kwin and KDE works this way because it was designed for x.org, and that changing it to work like Weston would essentially require rewriting large parts of KDE instead of just Kwin.

[funkSTAR]

Sigh. Another day, another example of KDEs technical debt. So SSD vs CSD is a complex matter and the CSD approach do offer some great advantages. However this doesnt matter now. CSD on kwin was put down not because CSD is bad but because KDE is uable to do it.

It is KDE excluding CSD, not the other way around. Starting to hate CSD is the wrong approach here. Whats next? If ppl drinks the anti-CSD koolaid they might as well drink the "kwin hates resolution negotiation" koolaid. KwinS limitations are really the problem not CSD, resolution changes or other stuff. This isnt the last blog from kwin devs trying to justify self inflicted limitation and tech hate. The world would be a better place without kwin.

[cardboard]

Sigh. Another day, another example of KDEs technical debt. So SSD vs CSD is a complex matter and the CSD approach do offer some great advantages. However this doesnt matter now. CSD on kwin was put down not because CSD is bad but because KDE is uable to do it.

It is KDE excluding CSD, not the other way around. Starting to hate CSD is the wrong approach here. Whats next? If ppl drinks the anti-CSD koolaid they might as well drink the "kwin hates resolution negotiation" koolaid. KwinS limitations are really the problem not CSD, resolution changes or other stuff. This isnt the last blog from kwin devs trying to justify self inflicted limitation and tech hate. The world would be a better place without kwin.

KWin has no problem not drawing a titlebar and borders, I assure you; there are even settings and triggers for it.

[newwen]

Does Wayland provide a protocol to tell the compositor if the window is closable, minimizable, resizeable or if it lacks decoration at all? I'd think so, since server is also a window manager.

But what if you're running a wayland application what does client side decorations? Would Kwin render a window decoration on top of the Window (just like compiz is doing now for Chrome, for example)?

What if you want to run a KDE application on another wayland server that doesn't support server side decorations?

I believe, that wayland server should let the client decide if it wants decorations or not each window, but compliant wayland servers should implement both, client and server side decorations. Otherwise, compatibility among servers, toolkits and applications will be a mess. Weston is thus, a bad reference server right now. Kwin is also a bad server if it doesn't allow CSD.

Wayland compliance should enforce supporting both SSD and CSD

[ninez]

First of all I find it hilarious that proper wobbly windows and rotating windows are the arguments for client side decorations.
Those two are hardly important use cases to solve if you ask me, compared to the serious usability problems that will appear if one goes with CSD.
For a proper working CSD each window would need to know as much about its surroundings as the window manager itself does, in order to make sane decisions, and then we are still talking heavy IPC.
On the other hand, since the compositor and window manager are truly one now in wayland with no other layers causing problems I can't imagine it being that hard drawing the decoration and window content to the same buffer before doing the transformations, hence solving the possible wobbly window problem.

lol... I don't think anyone was making the argument that Wobbly windows is a good reason for CSD - in fact, NO ONE in this thread made that claim. (which begs the question - how did you even come to that nonsensical conclusion?) Wobbly Windows simply exposes some bad rendering. ie: it was an example. (I don't use wobbly windows at all, nor does Liam, nor do i use any other fancy desktop effects).

Interesting point on IPC in CSD, i guess time will tell which ends up being better in Wayland.