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

[Britoid]

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?

That's because the underlying Win32 and Cocoa APIs are drawing the decorations when use their native toolkits to create windows (you can see SDL doing this here https://github.com/spurious/SDL-mirr..._cocoawindow.m). This is the supported method on those platforms. Linux doesn't have "one toolkit" and the job of window decorations under X has historically been the window manager.

The idea GTK follows is similar to the former model, if you want a window on the desktop, you create a GtkWindow and draw to it and the underlying GTK apis handle the decoration for you. This is maybe a contentious issue.

[schmidtbag]

Am I the only KDE user who doesn't give a crap about CSD/SSD? Why is this such a big deal? I've used GNOME apps on KDE for years and was never bothered by this. It's noticeable, but a lack of consistency is everywhere you go, even on Windows, Mac, and Android. Can we drop this?

[Gusar]

The idea GTK follows is similar to the former model, if you want a window on the desktop, you create a GtkWindow and draw to it and the underlying GTK apis handle the decoration for you. This is maybe a contentious issue.

Yeah, the argument is that applications shouldn't need to link to GTK just to get decorations. mpv is a low-level application, a GTK dependency would be overkill (mpv works without any windowing system, it can optionally use GBM/DRM to draw directly to the screen and that's with opengl rendering and hardware video decoding). Especially when it wouldn't be necessary if the Gnome devs implemented xdg-decoration.

[aufkrawall]

Sorry, I'm not smart enough to follow (let alone understand) anything related to KWin graphics! I can read and track bug reports though. Do you happen to have the URL handy for the bug report tracking this issue?

I once opened this and closed it in anger:

https://bugs.kde.org/show_bug.cgi?id=397850

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.

With free drivers, it is not about tearing, but about stutter. With proper compositors like Picom, Gnome-Mutter and kwin-lowlatency, applications like Firefox or mpv don't show any additional stutter vs. no compositor.

[Britoid]

Yeah, the argument is that applications shouldn't need to link to GTK just to get decorations. mpv is a low-level application, a GTK dependency would be overkill (mpv works without any windowing system, it can optionally use GBM/DRM to draw directly to the screen and that's with opengl rendering and hardware video decoding). Especially when it wouldn't be necessary if the Gnome devs implemented xdg-decoration.

There is a library someones working on that's a way of applications to get basic decorations (called libdecoration) without having to rely on GTK under GNOME. I'm not sure how far it's got, but that might be the way forward.

[ssokolow]

The idea GTK follows is similar to the former model, if you want a window on the desktop, you create a GtkWindow and draw to it and the underlying GTK apis handle the decoration for you. This is maybe a contentious issue.

Yeah, because, if the GTK+ people aren't willing to implement xdg-decoration, then they should accept Qt as "the platform's native toolkit" and link against it. Problem solved.

(What? It's just as arrogant and ridiculous as the GTK+ devs acting like children and expecting to push their toolkit on everyone else when it's hard enough getting game developers to just test their SDL-based ports properly in the face of things like multi-monitor desktops.)

[tildearrow]

tildearrow We discuss CSD because the news topic is CSD.

You are so annoying!
The news topic is about KDE's weekly report!!!

[finalzone]

Yeah, because, if the GTK+ people aren't willing to implement xdg-decoration, then they should accept Qt as "the platform's native toolkit" and link against it. Problem solved.

(What? It's just as arrogant and ridiculous as the GTK+ devs acting like children and expecting to push their toolkit on everyone else when it's hard enough getting game developers to just test their SDL-based ports properly in the face of things like multi-monitor desktops.)

Same applie to Qt developers. Let focus on proper communication please regardless the fanaticism.

[ssokolow]

Same applie to Qt developers. Let focus on proper communication please regardless the fanaticism.

I'm not at all a fanatic. I'm saying that it's ludicrous and juvenile for any set of toolkit developers to unilaterally declare that the only acceptable solution is for others to either add their toolkit as a dependency or reinvent part of it. (The latter of which will still produce an inferior result unless their theming system is also reinvented.)

[ngraham]

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.

It doesn't matter what their design vision is; we now support it. They can't force us to use CSDs for our apps any more than we can force them to abandon them. Yes, this leads to some inconsistency in that some apps use SSDs and some use CSDs. That's the price of window decoration diversity. Given that we can't unify everything, our next best choice is to try to integrate CSDs well enough that the differences don't regress usability any further and aren't visually jarring.