KDE Now Deals With GTK CSD Headerbars - Improving GNOME App Integration On Plasma

[bug77]

R41N3R Consistency comes with proper design, not dumbing down with SSD.

All power to the app devs and users.

GTK+: "Hey, 1,000,000+ app developers out there, here's an API so that you can paint windows decorations any way you want. Just make sure to be all consistent with each other or else it's your fault."

[Morty]

Decoration freedom is an anti-feature just like init freedom. .

Again a argument for SSD.

[ngraham]

Here's the thing guys: we don't really need to fight over CSD vs SSD anymore. I'm in the "SSD forever" camp (see https://pointieststick.com/2018/12/18/on-headerbars/ if you want to spend an afternoon on this topic), but the point of getting this support in KWin is to make CSD apps look and feel fine in Plasma. CSD apps aren't going anywhere, so we could either fight and make noise and generate friction and irritate our users forever, or we could acknowledge reality and support something that we don't think it optimal. I'm quite happy that we chose the latter.

[bug77]

Here's the thing guys: we don't really need to fight over CSD vs SSD anymore. I'm in the "SSD forever" camp (see https://pointieststick.com/2018/12/18/on-headerbars/ if you want to spend an afternoon on this topic), but the point of getting this support in KWin is to make CSD apps look and feel fine in Plasma. CSD apps aren't going anywhere, so we could either fight and make noise and generate friction and irritate our users forever, or we could acknowledge reality and support something that we don't think it optimal. I'm quite happy that we chose the latter.

The point is not whether KDE supports CSD or not. The point is the whole GTK+ camp think everybody should support only CSD (because that's what they do) and somehow still enforce consistency. You can't win that argument, you can't put it to rest.

[Gusar]

Gusar Your assumptions and guessing about my motives is just wrong, no further comments or reactions to that kind of behavior.

So... you can't argue my points and admit defeat, got it.

Decoration freedom is an anti-feature just like init freedom. There’s very good reasons why the industry moved to CSDs.

The industry did *not* move to CSD, you're just again ignoring the facts that don't fit your agenda. And no, "decoration freedom" (what kind of terminology is this anyway, is this a civil rights movement or something?) isn't an anti-feature, as ngraham says it's very much possible to have it both ways. KDE implemented GTK_FRAME_EXTENTS, now if Gnome implemented xdg-decoration we'd be more or less set when it comes to the two major DEs.

[Britoid]

No, Linux did not move to CSD. The xdg-decoration protocol is part of wayland-protocols, because some devs clearly do recognize the validity of both CSD and SSD. Same with Windows, it provides SSDs to applications that don't draw decorations themselves. Mac has always been Apple's "we know what's best for you and you'll like it", so the exact opposite of any sort of "freedom".

Under Windows the decorations are drawn by badly documented win32 apis. If you try and draw to 1,1 under on the window surface under Windows you will draw on the titlebar. Windows does a pretty good job at abstracting this though, since under Windows toolkits are not expected to directly talk to the compositor (and you shouldn't).

The window manager drawing window decorations is really an X specific thing. Wayland forgoes this because Wayland doesn't have the concept of windows.

macOS decorations are drawn by NSWindow (Cocoa), again apps don't directly talk to the compositor. SDL, Qt etc all under macOS create a NSWindow and draw to it (macOS even provides a OpenGL window context to make this easier). This is the direction GTK seems to want and apps like Firefox do this already.

TLDR: Client-side decoration is the norm outside of the Xorg world. GTK used a non-standard protocol to make it work better under X that KDE now supports.

[Charlie68]

ngraham (sorry for ringing you like this each Sunday ): Any news about fixed KWin vsync on Xorg? It's really terrible that you can't recommend Plasma to anybody without adding "But you should replace KWin with Picom or kwin-lowlatency fork.".

I think it's a hardware-specific problem, for example on my PCs I don't have any tearing problems with Plasma.
I had them when I used Nvidia (proprietary drivers), but with that Nvidia card I was fighting to solve it with all the DEs. Avoiding Nvidia was the solution on my desktop, I don't know if this is also your case, but if it were, remember next time to avoid Nvidia. If instead you have an Intel or Amd card, maybe you have been very unlucky.

[tildearrow]

See? This could have been a clean conversation, but 144Hz comes with his CSD (secretly pro-GNOME) propaganda and now everyone fights him.

[Britoid]

See? This could have been a clean conversation, but 144Hz comes with his CSD (secretly pro-GNOME) propaganda and now everyone fights him.

The problem with these discussions is that people confuse client-side decoration (a technical decision) with gtks headerbars (a design decision), although the latter requires the former.

[Gusar]

Britoid Let me provide a practical example: mpv isn't doing anything special on Windows in regards to decorations. It isn't doing anything special on MacOS in regards to decorations. It isn't doing anything special on [insert non-Gnome Linux environment here] in regards to decorations. It's only Gnome/Wayland users that are complaining "mpv doesn't have window decorations". So whatever the underlying implementation details on each system may be, clearly Gnome/Wayland is the outlier, requiring special handling that's not necessary anywhere else. SDL applications are in the exact same position as mpv.

tildearrow Is it just me or is 144Hz giving off a very GhostOfFunks vibe?