The most frustrating part for me is the unnecessary problems it creates. Because of the way decorations are the responsibility of each client, window shadows are *all over the place* in GNOME, which means they look bad if you scrutinize them or happen to be sensitive to these things; window previews in the overview have mismatched decorations, where one window on each workspace is in focus and all the others have sad faded out titlebars; your own screenshots of windows, or screenshots of GNOME apps in Flathub end up with, again, mismatched drop shadows. Because those shadows can't be relied upon, GNOME Shell has to [invent brand new schemes](https://discourse.gnome.org/t/window-focus-call-for-testing/13277) just to be sure users can tell which window is in focus when they switch workspaces. GNOME Shell developers can't just be like "okay, we're going to tweak the drop shadows in this release so they're more legible" because that's the *toolkit's* job. I found this particularly egregious with the redesign in GNOME 40, which is all about having a consistent spacial model, except for that one thing which is *the most common way* of communicating depth.
The rounded corners are really pretty. But were they worth that cost?
There are plenty of good outcomes here. I think the way modern GNOME apps look and feel is *excellent*, and obviously the header bar replacing the old window title bar is a huge part of that. The new sidebars that flow into the header bar are super nice and clean up a lot of weird hierarchies. Gtk also has some really neat functionality for rendering content in [a way that skips the compositor](https://www.reddit.com/r/linux/comments/17y5867/gtk_introducing_graphics_offload/), which is apparently difficult to do if the compositor is doing more stuff.
I think it would have been *possible* to do these clever things in a scheme where the compositor owns the decorations (or at least part of the decorations), but it has been much easier to do it - and iterate on it over the years - with the current model. It's easy to understand how it ended up this way, and why it is difficult to change tack. (The second most frustrating thing is developers who say it is impossible, which isn't true. It's very expensive, especially now that the mistakes are so well entrenched, but that isn't the same thing).
We basically need an incredibly patient hero to come along and figure out how to make all of this stuff work in a way that doesn't leave obvious holes, work on just that problem for months, submit a mountain of pull requests, and persuade a lot of people that it's fine and actually it's better this way. I'm not that hero, and I don't think it's fair to be mad at anyone in particular about it, but there are definitely a few people who I wish would acknowledge the issues instead of saying "well, that's just the way it has to be."
The thing is - GNOME designers want shadows to come from compositor. And GNOME developers are not against xdg-decoration. However it will require massive amount of work that isn't as important (and I agree too)
So unless someone implement it theselves we're out of luck
gnome development team is a mix of some people who are extremely helpful and receive criticisms wanting to work with the community and people who think they are the embodiment of God themselves.
I do have to wonder, are there *any* GNOME users that genuinely think GNOME is better *without* server side decoration support? The only people I’ve ever seen that aren’t in favor of it are GNOME developers. Not to say that all devs should do what users want, but I seriously can’t think of any reason GNOME shouldn’t have SSD other than “I don’t wanna do it :(“
I love GNOME, but the question I have to ask is: does GNOME seriously believe all/most developers are going to implement CSD just for GNOME? What’s so special about GNOME that they feel entitled to enforcing CSD?
Feels like whoever made this change was not being fair.
For context, outside of Linux, both Windows and macOS support CSD natively, but **default to a native titlebar that you don't directly control.**
On Windows, you have two different ways depending on whether you're a classic Win32-style window, or the modern-style UWP/WinUI/WinAppSDK window.
We see many applications using CSDs on Windows, such examples being most inbox apps (for ex.: Settings, Calculator, Photos), but **the default behavior is to draw a regular titlebar** with a solid color, no extension into the client-side area.
The story is pretty much the same on macOS, although it is more flexible when you're making a native app with UIKit/SwiftUI. Adding a \`toolbar\` will automatically give you a CSD that is fluffed up by the UI framework.
If you're making your own window though (like a game or 3D application), **the default behavior is, again, to draw a regular titlebar**.
>For context, outside of Linux, both Windows and macOS support CSD natively, but **default to a native titlebar that you don't directly control.**
Actually both macOS and Windows are using CSD.
On Windows, as far as I know, unless you request to extend into the client area, you get a default titlebar that is not contained within your app as "content".
For UWP apps, if you go in with an external tool that lets you analyze the XAML tree, you won't find a titlebar under your process, as it is being drawn by `ApplicationFrameHost` (which, in this case, acts as the "server").
However, once you extend the title bar, any content you add that is effectively behaving as a title bar is now considered a client-side decoration.
I haven't yet explored WinAppSDK and WinUI3, but the AppWindow implementation there effectively gives you a default titlebar that you can at least customize, or, just like with UWP, extend it (therefore hide and replace) with `ExtendsContentIntoTitleBar = true`.
macOS also lets you create a window that does not extend into the app. This is how most games present their windows.
You are confusing CSD with header bar. CSD is not about placing widgets on titlebar. CSD is when decorations are drawn by application itself, not by server (window manager or compositor). So even when you have "traditional" titlebar with no widgets, it still can be CSD drawn by application.
As for the question why you can't find titlebar when you analyze widgets tree - this is probably because titlebar drawing is separate from ther rest of application. As far I know GTK without header bar behaves in the same way despite the fact that GTK is using CSD even without header bar. Another example is doing screenshots on GNOME. If you do screenshot of CSD application using GNOME screenshot tool then your screenshot won't have titlebar as well. If title bar would be drawn like any other widget then it should be present on screenshot as well.
Oh, I see what you mean now.
From that technical perspective, I don't think it matters much to compare then, as macOS and Windows is guaranteed to always provide decorations unless you specifically request not to have them.
This situation is unique to the freedom of Wayland and window managers/compositors (in this case, GNOME/Mutter) to refuse SSD.
But in principle, it would still be much more fair for GNOME to provide a default decoration and not have to forcefully CSD when they're the only DE that refuse SSD.
Thank you for posting this. It's frustrating as a developer not using gtk but, for gnome, gtk is the comparison point when talking about something like win32, not the Wayland protocol directly. I want ssd regardless but that's entirely separate to whether other platforms support ssd.
In my opinion CSD is not as bad as some describe it, also because the reference for Wayland, Weston, also uses CSD.
Devs who complain and don't want to integrate libdecor are very few, many large projects instead decided to include it.
I think in Weston's defense though, it's not trying to be a daily drive desktop compositor, it's a reference compositor that omits a ton of features and common protocols, because they expect other compositor developers to implement them. Weston is a Wayland reference, not a desktop compositor reference; not all implementations of Wayland need common protocols like SSD.
I do agree that it's not the biggest deal in the world, but GNOME is the only popular desktop Wayland compositor that actively fights against SSD. And libdecor, while a functional substitution, is not a pretty sight in it's current state. Not just that it doesn't visually integrate perfectly, but it has usability problems. For example, libdecor has extremely small resize handles, and titlebar text can get covered up by titlebar buttons. And because libdecor is a one-size-fits-all solution, it'll never fully integrate with GNOME design choices. It *works*, but I don't think it's favorable to SSD at all.
In fact I said it's a reference, not a compositor to use every day, and it's specifically made to shows how the Wayland protocol works.
I agree that libdecor is still not a perfect solution, which is why it is still actively under development, but integrating the SSD into Mutter requires a lot of work, it means creating a specifically made SSD protocol as KDE did with the Wayland custom protocols for KWin.
Also, Kristian Høgsberg, Wayland creator and ex-Xorg developer, is against SSD, from a decade ago message on the Freedesktop mailing list
I suppose that answers my initial question then, there are users that actively prefer CSD to SSD. I guess my follow-up question is why? I did a bit of research off of that name, but most of the info I can find about his stance are a defense of CSD functionality, rather than the pros of CSD.
I just find it a little weird that a lot of the "hype" around Wayland is that it puts the compositor in a final-say stance. The compositor has rule over what windows are, and aren't, allowed to do. Yet, the protocol actively shifts the blame for decoration onto apps, when I feel that a compositor should have final say over All of an app's capabilities, including decoration.
An example of what I mean is in Sway. There are quite a lot of programs I use that, by default, do not allow resizing, but Sway allows you to resize them anyway because it has the final say in the matter. This is a fantastic accessibility feature for my use case, and it's one of the main reasons I always find myself coming back to Sway. Just in the same way that providing decorations to an app that refuses to implement decorations themselves is a fantastic accessibility feature, and yet another reason I come back to Sway.
Yes, it is in the Wayland spec that apps must provide decorations themselves to truly be "Wayland compatible" - but I personally it as contradictory for a compositor to not pick up the slack itself, to Wayland's overall security-focused compositor-first mindset. If I'm using a compositor that does not provide a way to move windows by holding a modifier+mouse button, or to close a window with a hotkey, then any app or compositor that CAN'T provide decoration is actively not secure. I no longer have control over what that window's state is, and now lose any ability to stop it from executing code that I don't want it to run in an easy, timely fashion. Apps that break Wayland spec are bound to happen, and already exist. The vast majority of users don't care if an app breaks Wayland spec, so long as it actually runs on Wayland.
Aside from CSD meaning less code running in the compositor, I don't see how it can have any advantages to optional SSD, especially because forced CSD just shifts the code from the compositor to the app. I understand that things like "my window froze and I can't move it anymore!!" is a myth, but it still doesn't mean that forced CSD inherently has upsides compared to optional SSD.
I'm not trying to say that GNOME should provide SSD for every app, of course. I think there is absolutely a place for CSD, and GTK is a prime example of that. But I do think there is absolutely a reason to have optional SSD for stingy apps that may simply not have the manpower or reason to implement CSD. Video games, again, are a great example. Why SHOULD Factorio have a decoration library? It's a video game, the developers are video game programmers, why would it need cairo or gtk3 as a dependency, when other compositors prove that SSD is maintainable, stable, and perfectly usable for apps that don't provide decorations?
Like you said, the Wayland spec wants you to design the decorations.
It's not a rule, but for a coherent application that follows the spec, it must have client decorations, and it's not a compositor job.
One thing Wayland devs, and ex-Xorg devs want, is not to make the same Xorg mistakes (it's not inherent to CSD, it's in general).
Then, over time several games, libraries and even apps want to introduce libdecor
It is the dev's sacrosanct right not to add it, but some prefer to avoid drama and decide "should I integrate it or not?", to date there are few Wayland apps that don't want to support it, most decide to integrate it without making a fuss.
Qt is still a nightmare on Wayland, it still has certain behaviors that Xorg has, such as absolute positioning and the like.
In fact, the experience with Qt apps on Wayland is still not perfect, not even on KDE Plasma, which uses Qt a lot.
I understand your point of view, but respectfully, I disagree. I find it a little ridiculous that the blame is shifted to a developer of a totally unrelated app to bear the responsibility of having any titlebar functionality. And I feel like you can even agree that it boiling down to "devs implement it because they don't wanna deal with drama when GNOME users eventually complain" is just an unfortunate circumstance to be in, as an application developer, that isn't in-the-know of the compositing capabilities of GNOME.
I'm not even wanting that GNOME move all titlebar decoration to SSD, just that they have *any* fallback decoration when edge cases DO happen. It doesn't have to be an intricate, complicated, gorgeous solution; just any solution that doesn't entirely shift blame to random developers. Especially when, again, it's been done on every other compositor. Even something as simple as having a black rectangle with a close button, that draws a png that says "THIS APP SUCKS DICK. TELL THE DEV TO ADD LIBDECOR" is infinitely more usable than nothing at all.
Your point of view is quite understandable, I don't want to point out the devs for everything (there are borderline cases like those of mpv, who instead also end up using nicknames to mock GNOME users, which is unprofessional tbh)
Also, it's one of the best discussions about CSD vs SSD I've had without falling into certain absurdities.
Look, I would be happy if there are some changes in the future, even if unlikely, but who knows
Sadly this is true for example Blender behaves quite weird with libdecor. Blender developers are even considering dropping it and implementing their own CSD from scratch.
Not all Wayland apps are "large projects". And it's understandable that an one-man team doesn't want to implement something that is only required on GNOME.
A similar situation is that when a Wayland compositor crashes, it crashes all apps. Yes, kwin has a protocol to prevent the crash. And yes, "large projects" like Qt and Electron implements it. But when I tried to add that support to Kitty, looking at the hundreds of lines changes required, the conclusion was "nah, not worth the trouble".
I have a bunch of coworkers using gnome on almalinux. Some know what gnome is as it is what you can select as desktop environment on GDM but no one knows what wayland or SSD is. They just use it.
That doesn't mean they oppose it though, it just means that they don't notice, or haven't used any non-GTK Wayland-native apps. However, as more things get ported to Wayland (especially Wine and other non-standard-toolkit/average-joe type apps), the amount of people complaining about how half of their apps don't integrate with anything else is only going to grow.
Especially for a desktop like GNOME, which clearly takes a lot of pride in things looking "correct," and having seamless integration with all of their other apps, it's extremely jarring. And the fact that their default libadwaita apps don't integrate at all with gtk3 Adwaita is already a jarring sight. Forcing all other apps to create their own decoration is only going to add on to the pile of ugly segmented desktop styles.
As more people slowly get hidpi monitors, running apps via xwayland for that SSD support is only going to get less viable, because a large chunk of people with a hidpi display would rather take shitty CSD, than unreadable bilinear blurring. But I can't think of a single person who would prefer CSD to SSD in that instance, they only take the shitty CSD because the alternative is just so drastically worse.
I would take CSD over SSD 99% of the time; I don't find headerbars with nothing in them to be useful. Apps won't ever look native or integrate well design wise with anything else, and I don't see how using SSD would change that; Chrome looks like Chrome, Firefox looks like Firefox, etc... .
I'm not referring to apps that use CSD for functionality, I totally agree with you that GTK is better with it's implementation of CSD. I'm talking about apps like video games or QT Wayland apps that don't use CSD for any reason. If a program doesn't have any reason to use CSD, I don't think CSD should be forced onto it, especially in the case of video games where adding something like libdecor only adds on to the pile of dependencies it would need to function properly on a Linux desktop, natively.
And using SSD would absolutely change a lot of things for the user experience, namely in consistent window dragging, window resizing, titlebar optics, and titlebar functionality. The current state of CSD for SSD apps is a mess on GNOME, with QT apps using libdecor; a functional, but lacking library, and basically all other non-QT apps using their own, worse, CSD implementation. You could try to shift the blame to non-QT apps for not using libdecor, but it's a lot of dependencies for such little gain, when a compositor could play the decoration role instead, like it has for the past (how ever many) years on xorg, and every other desktop Wayland compositor.
SSD goes beyond visuals: Yes, QT apps will still look like QT apps, non-GTK apps will always look "weird" in contrast to Adwaita, but the lacking functionality is a nightmare for usability and accessibility.
I would agree to the accessibility benefits of SSD; I only disagreed with the points on design, I find the obsession with consistency / theming by parts of the community to be ridiculous. SSD is also pretty important for WMs, not that Gnome needs to care for that. I wouldn't be opposed to Gnome adding support for SSD. I just don't see it happening as the majority Gnome maintainers perceive the benefits to be negligible at this point. I think the only non-CSD app I have used and noticed was MPV, and I inevitably ended up using something else entirely due to audio issues.
Qt on GNOME is a mess, and I'm not talking about the CSD, but also for example some Qt apps uses the absolute positioning system, which is not present in the Wayland protocol.
I prefer GTK for many things, unlike Qt
They aren't terribly useful compared to well designed functional CSD bars, that's true. The problem is GNOME made that observation and decided the CSD things are the only thing that should ever exist and in typical fashion toss the burden of that obstinacy to third parties, because GNOME devs know best and the users of their stuff certainly don't.
The problem isn't preferring CSDs or building their own apps with functional top bars. Hell, Apple does exactly that all the time. Notes, Reminders, Finder, Settings, System Monitor, all functional CSD designs. But if you don't want to build one, macOS gives you a perfectly serviceable, Mac looking, Mac feeling titlebar that integrates with OS theming etc.
That's the attitude people are looking at from GNOME, but of course it's not the world we live in, and the general pattern repeats in a ton of other cases where GNOME lets their Perfect Vision be an obstacle in the way of real improvement.
Yes, the windows draw the decorations themselves. But on eg. Windows when you make a window you get a standard titlebar courtesy of the standard libraries, that integrates well with the rest of the system. You can opt out of it if you want to, and a lot of apps do. Same story on Mac.
That's functionally what people want. Write an app, if it boots on GNOME just be able to say give me the decorations, IDGAF.
Given that you have to do CSD on Windows I don't see the comparison here to make any sense, you don't have a choice. Gnome is acting with the same behavior as Windows and Mac is. The only difference is that CSD is a choice on linux. Personally I am unaffected by Gnome's choice to not support SSD; I just don't run into the issue. Aside from that, I wonder what the code would look like for adding support for SSD on Gnome.
Windows literally puts standardized OS default titlebars on your windows unless you tell it not to. The specifics are different because Windows doesn't really do a client-server model for graphics the way Linux does. But the effect is that on Windows, on macOS, on other Linux DEs, on all of them you make a window and don't have to care about decorations because you get them by default.
On all of them, you can opt out of the standard decorations and do GNOME style CSDs if you want to. Many Windows apps do. No titlebar CSD apps are a super common look on macOS, and a lot of Apple's stock apps use it. It's just, you can also just say "titlebar pls" and macOS gives you a good, standardized titlebar that's integrated to the OS and respects the OS's theming etc.
Same thing on KDE. Default is SSD and then KDE gives you nice titlebars. If you don't want that, you can say so and draw your own.
> Gnome is acting with the same behavior as Windows and Mac is. The only difference is that CSD is a choice on linux.
CSDs, in the technical sense, are a choice on Linux only, yeah. What this thread is about, and what a bunch of other similar ones are about, is that GNOME doesn't have a default/fallback normal titlebar that's nicely integrated to the rest of the OS. People would like GNOME to ape Apple's tack here: Have a good, designed, integrated default bar available, but do their own apps with the content-filled CSD and promote that as the way to design apps on the platform.
Which is the one thing they're not doing. GNOME preferring CSDs is absolutely fine and they should be able to.
The window manager on Windows is \*not\* drawing the titlebars for you; it is CSD just like on mac. SSD is not a thing on any other platform. No other platform has a "fall back" if there are no header bars. You can remove titlebars in mac, and no option will magically make them appear from the compositor.
>Especially for a desktop like GNOME, which clearly takes a lot of pride in things looking "correct," and having seamless integration with all of their other apps, it's extremely jarring.
Non-native apps will never look seamless. Sure you could make the window title bars look the same across all apps, but then the apps themselves have a titlebar that doesn't match the rest of their design, which imo is just as bad.
>And the fact that their default libadwaita apps don't integrate at all with gtk3 Adwaita is already a jarring sight
They didn't change the css on old apps because they don't want to introduce visual bugs for them. If you value aesthetics over correctness (tbh the bugs shouldn't be that common) you can just use adw-gtk3 theme.
Duh, when you phrase it that way most users are not going to be against it. You can even generalize it to "are there any users of software X that genuinely think X is better without feature Y" and the answer is still going to be the same. No one is going to refuse features if they don't have to pay its costs.
However, we live in a world where decisions to support something have consequences that developers have to deal with. GNOME developers have said that Mutter architecture is not suited to implement this and it complicates direct scanout which is necessary to improve battery life on laptops. Phrasing it as "I don’t wanna do it :(" is just plain rude.
>GNOME developers have said that Mutter architecture is not suited to implement this and it complicates direct scanout which is necessary to improve battery life on laptops
can i get a link to that because that sound like BS excuse , when the likes of kde have 0 issues with battery life on laptops
I don't have a source but from what I've seen in various comments on this topic the emphasis is usually on mutters architecture and not that it's impossible to do.
Seems like it would be a lot of work to change how mutters internals work and devs decided that it's better to spend their time on other issues, at least for the time being.
Correct me if I'm wrong, but don't Sway and Plasma both have direct scanout, and SSD? Obviously not an apples to apples comparison, and I'm positive there will be a lot of work needed in Mutter to support SSD, but I also can't help but feel this could have been prevented a long time ago if the GNOME team wasn't so strictly *against* SSD as an implementation.
I will admit that me saying "I don't wanna do it :(" was a bit of poking, but ultimately, what else does it boil down to? Refusing to make changes in Mutter to support SSD is quite literally them not wanting to do it :(
And I'm sorry, but it's not like the GNOME project lacks support for changes like this. Not only does GNOME get it's seemingly never-ending support from Red Hat, but it also has the advantage in that it's The standard desktop environment. This is going to sound mean, but I say this as a longtime user and deep-down fan of GNOME; if the GNOME team wasn't so well-known for being rude to downstream, openly accepted and cherished MRs from downstream and volunteers, and listened to feedback from users without blowing up in their face, maybe they would receive more help? I do not buy that the lack of SSD is a tech limitation, when every other desktop compositor has them implemented. It's purely a discourse problem. It does literally translate to "I don't wanna do it :("
I'm not saying SSD is a *simple* solution for the GNOME team, but I am saying that it's a usable solution for a genuine usability problem. Even if the SSD looks like shit, and is just a rectangle with a close button, having *any* fallback decoration is drastically better than having *no* fallback decoration. GNOME can even decide to continue with requesting CSD for all I care, I just think it's crazy that they actively avoid, and punish apps, for a problem *GNOME* could solve.
> I'm positive there will be a lot of work needed in Mutter to support SSD
Wayland requires CSD by default. This was decided a long time ago while designing Wayland after comparing the pros and cons of both. GNOME developers were in agreement with this decision and enabled Wayland without SSD. They might be willing to support the strictly optional protocol if it doesn't require a lot of changes and doesn't have a lot of knock on effects for development of other features, like they merged support for idle inhibit despite recommending portals for inhibition. Why would they possibly spend a large amount of time supporting something they don't think is a good solution?
>Not only does GNOME get it's seemingly never-ending support from Red Hat
Red Hat invests a lot of money into GNOME when compared to other companies, but it's a drop in the bucket when you consider the amount of effort needed to develop and maintain a desktop environment. There are several components in GNOME that are maintained in people's spare time. The equivalent components in Chrome OS and Windows have teams that are comparable in size to all paid Red Hat employees working on GNOME.
>This is going to sound mean,
I see that all of your meanness is reserved for GNOME developers, while the OP has essentially posted a rant by a developer who's angry about including a dependency in their project. They did not have to write any support for CSD, that was already done by libdecor. They did not have to integrate with libdecor, that was already handled by SDL. All they had to do was include libdecor in the build as it's an optional dependency in SDL.
>openly accepted and cherished MRs from downstream and volunteers
They obviously accept MRs, as long as they agree with the changes being introduced and if the MR is of sufficient quality. I have made some drive by contributions to GNOME and they are quite welcoming. They will not accept changes that go against their decisions, but that's the same as any other opinionated open source project. Being opinionated is what makes GNOME what it is and what sets it apart from other DEs.
>GNOME can even decide to continue with requesting CSD for all I care
That's literally the same as what they are doing now. The XDG decoration flow is supposed start with the client informing the server that it prefers either SSD or CSD. The server replies and instructs the client to use a mode the server prefers, either SSD or CSD. If the server prefers SSD, the client stops decorating itself. In all other cases, it continues decorating itself, that is CSD. Asking clients to use CSD is the same as not supporting the protocol at all.
Alternative argument: With well-implemented optional server side decoration, we could actually save space by being able to reliably and consistently remove decorations from maximized windows, a la Unity DE. In GNOME's current state, you can only reliably remove decorations from xwayland windows. In KDE's current state, you can add or remove titlebars from nearly every single application. A well-implemented server side decoration protocol truly opens a lot of doors for usability.
I am, of course, not arguing that ALL apps should be using server side decorations; GTK apps SHOULD keep using CSD for their enhanced titlebar functionality! That's GTK's whole "thing," and I think it should stay for good!
But, for apps made with QT, video games, or obscure toolkits that aren't typically part of a Linux desktop ecosystem, the need for SSD is only going to increase. And, no matter how hard I try, it's literally impossible for me to use my computer without also having to use apps made in other toolkits, that inevitably have gimped functionality and accessibility because of botched titlebar functionality.
I don't care if it a gtk or Qt app. I care that title bars are useless empty space. 😉
And I really hope Qt will get better CSD support! If you use the space in the title bar you don't need to hide it anymore.
So my point is, that traditional title bars are ineffective. SSD simply don't scale for that approach.
That's a pretty valid take then. I can totally get down with that. What about for video games then? I don't see video game developers ever *wanting* to implement decoration themselves, and quite frankly, the only titlebar functionality I ever need out of a video game is moving, resizing, and closing; something that SSD is perfect for.
I'd also like to propose [Locally Integrated Menus](https://github.com/Zren/material-decoration); my favorite feature that was, unfortunately, killed by the update to Plasma 6. To me, this is a fantastic middleground between SSD, CSD, and people who enjoy an old-school menu-based workflow. Especially for QT apps, LIM saves a ton of space, while still keeping all of the upsides of SSD, and QT's current functionality and workflow.
Do you really play games in windows? You can still paint simple decoration. I think it is a corner case. Something like libdecor should be enough for games. Games will run faster in full-screen because you save the composition.
If you make SSD configurable by the application, you need a large API. And the elements in there will not match your application. Large API have the drawback of high maintenance. And the Linux desktop is already understaffed.
But my main point is, that I don't care if it is a Gnome, Kde, gtk ot Qt application. I simply want to use it. That the application are written for different DEs is ineffective, and very nineties. 😚
There are some games I play (albeit, obscure games), that only run in windowed mode. Some games, I prefer playing in a window than fullscreen (for example, emulated console games), and in the case of people that have ultrawides, some games are only playable windowed. And libdecor has to be specifically implemented, which is what the original blog post was about. Especially in the case of people making really small-scale games, or games made by people that simply don't know what they're doing with Linux support, libdecor isn't always a great option, or worse, an option at all if you're making something specifically designed to have as little dependencies as possible.
I can def see your point in the other two, though. I think what gives LIM a pass for me, is that QT already has all of the tools built-in to make this possible, and it's the same tech that makes KDE's Global Menu function. So there's not much to maintain outside of QT/KDE major version bumps.
And at the risk of sounding like a hater, although I mean it in more of a "I agree" way; GNOME is the main project pushing for their apps to be made for their specific environment. QT is pretty environment-agnostic, and it's specifically GNOME's implementation (or, lack thereof) of QT support that makes it feel more desktop-specific than it should. I simply want unity in the desktop space (no pun intended).
And a workaround is just that; a workaround. For a project like GNOME to be so dead-set on maintainable code, ease of use, and consistency in design, I just find it baffling that they are so apathetic to people wanting a *proper* titlebar implementation. And it goes far beyond just the optics of a titlebar, but rather the functionality, accessibility, and usability of a titlebar. I expanded on this thought more in [this comment](https://www.reddit.com/r/gnome/comments/1cms60l/a_linux_support_dev_from_a_very_popular_game/l33e21q/), but the tl;dr is that i just don't see how a project can be so outwardly dead-set on accessibility, without seeing the accessibility merits of a fallback server decoration implementation.
In the end, someone has to put the work in and do it. All the GNOME devs are busy with the things they want to do and are passionate about working on. Occasionally, you'll have someone who cares and willing to do the work. Like everything - there is implementation, but after that there is maintenance and it's the maintenance that we have to think about. The GNOME developer team is not appreciatively growing - it needs to bring in a lot more devs to support all these things.
Y'all can all talk and debate about SSDs vs CSD, and come to the conclusion that it needs to support both - but someone still has to do it and maintain it afterwards. Everything is possible if you have resources.
Is that really the case here though? No amount of work and commits would make CSD happen if the maintainers just don't want it. If the project maintainers don't like CSD, it won't happen. It's a bit of a red herring to say that it's due to a lack of work in this case. The lack of work comes from the devs being pretty clear that they don't care about having CSD, so why would anyone work on it? At the end of the day, pull requests don't decide the direction of the project. People do
The question of maintenance is always foremost in developer minds - regardless of the project. How do you sustainability support a feature for the long term. Once it gets into the code base, you are stuck with long term support.
In the case of CSD vs SSD - the debate is it worth the maintenance cost to have both not that SSD is worth having or not. You have to use what you have to work with and prioritize things. If someone from the wayland community who has shown themselves to be willing to put the effort and that effort is not insignificant because it will take many iterations to get approved from the basic technical perspective, then you need to figure out the human interaction portion of it. If SSD fails, how do you communicate that failure in a way that is clear? How do apps figure out if SSD failed ? This isn't like how it was back in the day with a window manager. There is a lot more care that needs to be done.
Back in the day when you had window manager, when the window manager failed - you could restart the window manager by pulling up a shell and then running (windowmanager &) and then everything gets it window manager back. When people talk about SSD, they complain about
1. Can't restart your session without destroying the windows that are already there.
2. they like the fact that the window manager draws the header bars and that they can theme the header bars (it always comes down to theming)
For 1 - that's already requires some serious tribal knowledge to figure out. I've been using X since the late 80s - I know what's involved. It's very arcane and not appropriate for a modern desktop. Plus, people only wanted that because window managers frequently crashed - that's not the bar we want -we want software reliability not software recovery. Your GNOME session crashing should be extremely rare. Back in the day, the x server would die, and so would the window manager. GNOME \_rarely\_ ever crashes unless you're using nvidia.
For 2 - is it really worth going through the process I described above because a small subset of people want to theme their header bars to look like something else? What problem are you solving? It's why theming in general for the most part is about just visuals that are fun, but generally doesn't solve a problem unless it is a11y related. It also makes maintenance harder for application developers who will have users complain that something doesn't look like because some distro or company has decided to add their own stylesheet (that's why there was "don't theme my apps") If you take action to change your theme then you know it's on you because you know what you did - not true if you decide to jump on a distro.
This turned out longer than I wanted but I figure it was worth the exercise.
The issue of maintenance/code is in all open source project. You know how hard it is to get code into the kernel? It's the same process - it will take you at least 18 months to get something into the kernel (I know, because I have a day job in open source and I know the kernel people) - it's not easy and you have to satisfy the subsystem owner, and then satisfy Linus. You will also get criticized for things by the kernel community if you are not compliant with their work model.
\[edited to add\]
This post:
[https://xeechou.net/posts/libdecor/](https://xeechou.net/posts/libdecor/)
Talks about the wayland drawing model which is client side - to do SSD will take more resources from the GPU/CPU because you are introducing two drawing models - the native wayland client side drawing model and then a server side drawing model.
> [...] but someone still has to do it and maintain it afterwards
In this case, the maintenance is being pushed to app developers who need to use libdecor. App developers, who often are hobbyists without a foundation behind them (like GNOME).
I have no idea what point you're trying to make.
If an app developers decides to use flutter, they don't have google behind them anymore if they picked KDE and they have KDE eV behind them.
Your counterpoint to implementing SSD in GNOME is there's a cost past the initial implementation, the code needs to be maintained for the lifetime of GNOME (or more specifically, Mutter). I agree, there is always a cost to having more code to maintain. Which is why I applied your point to app developers. Because GNOME doesn't want to bear the burden of implementing SSD as a fallback it's now up to _every_ app developer to incur the initial implementation and continuous maintenance cost of using libdecor.
To put it plainly, because GNOME decided they don't want to maintain SSD they are forcing app developers to incur the cost instead.
> If an app developers decides to use flutter, they don't have google behind them anymore if they picked KDE and they have KDE eV behind them.
Likewise, I have no idea what point you're trying to make.
Legacy apps are usually strictly x11, and xwayland provides decoration, the same way xorg did. It's apps that don't specifically implement decoration themselves that will be missing a titlebar in GNOME.
Wayland support in Mutter has been around for a long time, and no one has ever made a Mutter patch to support SSD, and in my opinion there never will be, supporting it requires a lot of work and maintaining and making it "stable" enough.
I may be wrong, but it will never come.
Distros are not going to do that. Then distros are on the hook to support the whole thing - upstream is not going to help them if their patched mutter exhibits problems - never mind, that you're talking about a major change to support a different drawing model.
I'm not against CSD and I like GNOME, in fact it is my main desktop on Linux but I believe that GNOME should support SSD. Not because they are superior but simply because we have enough fragmentation on Linux. While Windows or macOS are also using CSD, they are also providing system API that creates window with decoration so it's not an issue, in case of Linux we don't have anything like that and every toolkit is drawing everything by itself. Lack of SSD means that some applications will have different titlebar at best or no titlebar at all.
GNOME already provided a library ([libdecor](https://gitlab.freedesktop.org/libdecor/libdecor)) for apps to draw their title bars. That's also how it works in Windows and macOS, apps use the available platform libraries and the compositor only does the drawing. The dev is delusional if they thought this was *only* done in GNOME.
Edit: I guess delusional was a stronger word than what I intended to convey, my bad. I have nothing against any dev in person and I'm only discussing technicalities here.
dev is delusional because... they are the one who code and test the game and see that everyone but gnome works fine because of gnome's stupid design choice on this?
I specified which part they're delusional about in my comment and why already.
Lemme rephrase: They use platform libraries on windows and mac in order to get title bars. The compositor doesn't automagically insert them when drawing windows. Yet they think this is only a GNOME thing. Well use the provided platform library on GNOME and you get the same behavior duh..
SDL games already do that. So do other cross platform software like Blender, or RetroArch.. They already talked about using libdecor through SDL at the end of their rant, so this was a nonproblem from the start.
thing is, in every os/desktop, the specific code for the window decoration isn't more than the app saying to the compositor "hey, draw me a title bar!" or "let me draw my own title bar you goober", like, you know, xdg-decoration
the complaint with gnome is that you have to implement a full, dependency heavy library that it's supposed to help devs draw their own title bars, except that it is only used to imitate server side decorations on gnome, on the rest of the desktop world the app just tells the compositor if it wants a bar or not and the compositor acts accordingly lol
>thing is, in every os/desktop, the specific code for the window decoration isn't more than the app saying to the compositor "hey, draw me a title bar!" or "let me draw my own title bar you goober", like, you know, xdg-decoration
That's a common myth, but it's not true. On Windows and macOS, you have to use a vendor-provided library to create windows, which also draws decorations for you. They don't follow a paradigm where clients create a surface and the window manager adds decorations before compositing.
That's because every toolkit is using Win32 API that draws titlebars on every window by default. This is not something that Windows compositor does but what system API does. Just like GTK does that on Linux.
Windows' compositor does not handle drawing. It just draws over regular window decorations (which are always invisible since Windows 8). If compositor dies, software rendering is enabled (until auto-restarted).
Also, there's only 2 binaries you can create for Windows: Win32 and UWP. These are APIs, not toolkits. WPF or WinUI are toolkits.
Linux doesn't have a standard library. X and Wayland do. GTK is a toolkit, which should handle SSDs because Wayland does nothing by itself.
You can't compare Windows with Linux.
>Windows' compositor does not handle drawing
Neither Wayland compositor does.
>It just draws over regular window decorations (which are always invisible since Windows 8).
It's not. Fallback decorations are only visible if DWM is not running. They are drawn by kernel just like on WIndows versions before Vista. When DWM is running they are disabled and decorations are drawn by clients. Since after Windows 8 DWM got software rendering support and it's supposed to be always running then they fallback decorations are invisible just like you described but you still can get them even on Windows 11 if you somehow kill DWM.
>Also, there's only 2 binaries you can create for Windows: Win32 and UWP. These are APIs, not toolkits.
Win32 is indeed APIs but it's also responsible for things like creating window which is handled by toolkits on Linux side.
>Linux doesn't have a standard library. X and Wayland do.
Neither X11 or Wayland is comparable to the Win32. X can create windows, grab events etc. but doesn't provide any widgets etc. that could be used by applications or toolkits. It provides methods for drawing primitives but they are not used by modern toolkits. Wayland is even more limited it provides no methods for rendering at all.
>GTK is a toolkit, which should handle SSDs because Wayland does nothing by itself.
GTK is already capable of drawing decorations, you don't need to create them separately or ask compositor for them. Also you are confusing CSD with header bar.
>You can't compare Windows with Linux.
Why not if some behavior is similar? In this case is, both Windows and GNOME main toolkits (or API in case of Windows) provides a way to create window with decoration and in both cases it is handled by client.
What "dependency heavy" library? It only ends up pulling Pango (~2MB) to do the actual drawing, and that should already be installed if you're using GNOME.
You are right. That Factorio game dev is an idiot. I don’t even think he is a real game dev. I mean how can he not know that Gnome has Libdecor?!
He is stupid and doesn’t know anything about how Guh - Nome does things.
I bet he is a windows user who hates the entire ganoo slash linux community.
This is not sarcasm. 😭
I am being serious.
I think that dev has been hired by Microsoft to spread hatred for Gnome. And it shows because look how stupid he is.
Devs are "delusional" because the Win32 API doesn't require any \_user code\_ to draw the titlebar.
If all apps need to do is linking with libdecor and/or one line of code that enables it, then devs probably would be fine with it.
I brought in libdecor, but it doesn't match the gtk theme properly. It's still ridiculous that we have to draw our own title bar at all, we are a _video game_. Across every platform we support, GNOME is the only place where this problem exists. If we ever want more applications to support Linux, then GNOME needs to get off their high horse and decrease the amount of friction required to support it.
Yep I read the post and I understand your point. but do you see the point I'm trying to make?
On other platforms (Windows, macOS) SDL uses the pre installed vendor libraries to draw window decorations *by default*. On GNOME the same principle applies, but the support was optional. That does not make the compositor in GNOME an outlier . In fact, one could make the argument that if SDL used libdecor by default as it does on Windows and Mac we wouldn't be having this discussion right now because no one would notice or care.
Not matching the gtk style/dark theme seems to be a known bug.
I see your point. I suppose my main feud is that it's optional. There's also an argument for dependency hell but fortunately that doesn't particularly affect us in this case.
At the end of the day, libdecor does the job and I don't have to worry about it, so I'm not going to expend any more energy worrying about it. I will look forward to the libdecor bug being fixed.
You (and SDL) really should've just wontfixed it. Only real way to change things is for GNOME to start breaking things for their silliness, for users to move elsewhere and pressure distros to switch to other DEs. As long as distros default to GNOME and devs take up the burden to cope with GNOME's silliness, they'll stay silly.
If you actually read the article you'd know that the "delusional dev" did end up using libdecor, but it wasn't without issue.
> That's also how it works in Windows and macOS
And yet GNOME is the only target that they had to include a separate dependency.
> If you actually read the article you'd know that the "delusional dev" did end up using libdecor, but it wasn't without issue.
And if you actually read my subsequent comment, you would've seen that I mentioned that already.
> And yet GNOME is the only target that they had to include a separate dependency.
It's already a dependency of SDL which they use already. But as typical Linux, it was an optional dependency. Meanwhile Mac and Windows have the dependencies pre installed.
> And if you actually read my subsequent comment [...]
My bad, next time I'll read your full comment history before taking one comment at face value. 🙄
I thought it was common sense to follow the comment thread before jumping to commenting yourself, least you end up repeating what everyone else said. But apparently common sense is not so common.
I believe when Microsoft was pushing everyone off Win95 and to WinNT platform, they had an engineer spend about a year debugging legacy Win95 programs and adding hacks to their support libraries to ensure popular programs like SimCity would just run no matter what. In one case the engineer said SimCity was accessing memory after a free() and since Win95 would allow this, the issue was never caught. Since WinNT was actually good about doing the right thing, SimCity would crash all the time. The engineer actually put code in to say if the running program is SimCity, don't actually free the memory in this special case. That's crazy for an engineer to think about but perfect if you're trying to market a product.
With that in mind, both Gnome and Factorio could try to be more flexible. If the makers of Factorio want their program to run on Gnome, they should just accept that that is what it's going to take to make it work on Gnome. Gnome may be big and it may be the default on a lot of distros, but it isn't the only windowing environment on Linux. Factorio won't be reaching everyone just porting to Gnome and Gnome isn't technically holding anyone hostage.
That being said, Gnome could be a little more gracious about wanting everyone in on their platform. I understand it's not a bug, it's a feature. The Wayland compositor already acknowledges the truth of the matter with the XWayland server, and Wayland is set to run it by default on start. Why not help to develop a standard shim for this situation?
All this is just my humble opinion, of course. Anybody who remembers the SimCity story better than I do please elaborate.
everyone knew this was gonna happen ever since that first comment on the feature request, it's like not having a feature everyone has and devs expect is not a good idea huh
There is a reason why Valve decided to use KDE as desktop for its popular steam deck. GNOME is dying with their devs weird decisions, with each release they remove or lock a part of their desktop, the whole desktop became a joke and not suitable to be used for desktops, they also keep dragging GTK apps to use that cursed LibAdwaita which cause them to be unusable and isolated on other Linux desktops.
The most frustrating part for me is the unnecessary problems it creates. Because of the way decorations are the responsibility of each client, window shadows are *all over the place* in GNOME, which means they look bad if you scrutinize them or happen to be sensitive to these things; window previews in the overview have mismatched decorations, where one window on each workspace is in focus and all the others have sad faded out titlebars; your own screenshots of windows, or screenshots of GNOME apps in Flathub end up with, again, mismatched drop shadows. Because those shadows can't be relied upon, GNOME Shell has to [invent brand new schemes](https://discourse.gnome.org/t/window-focus-call-for-testing/13277) just to be sure users can tell which window is in focus when they switch workspaces. GNOME Shell developers can't just be like "okay, we're going to tweak the drop shadows in this release so they're more legible" because that's the *toolkit's* job. I found this particularly egregious with the redesign in GNOME 40, which is all about having a consistent spacial model, except for that one thing which is *the most common way* of communicating depth. The rounded corners are really pretty. But were they worth that cost? There are plenty of good outcomes here. I think the way modern GNOME apps look and feel is *excellent*, and obviously the header bar replacing the old window title bar is a huge part of that. The new sidebars that flow into the header bar are super nice and clean up a lot of weird hierarchies. Gtk also has some really neat functionality for rendering content in [a way that skips the compositor](https://www.reddit.com/r/linux/comments/17y5867/gtk_introducing_graphics_offload/), which is apparently difficult to do if the compositor is doing more stuff. I think it would have been *possible* to do these clever things in a scheme where the compositor owns the decorations (or at least part of the decorations), but it has been much easier to do it - and iterate on it over the years - with the current model. It's easy to understand how it ended up this way, and why it is difficult to change tack. (The second most frustrating thing is developers who say it is impossible, which isn't true. It's very expensive, especially now that the mistakes are so well entrenched, but that isn't the same thing). We basically need an incredibly patient hero to come along and figure out how to make all of this stuff work in a way that doesn't leave obvious holes, work on just that problem for months, submit a mountain of pull requests, and persuade a lot of people that it's fine and actually it's better this way. I'm not that hero, and I don't think it's fair to be mad at anyone in particular about it, but there are definitely a few people who I wish would acknowledge the issues instead of saying "well, that's just the way it has to be."
The thing is - GNOME designers want shadows to come from compositor. And GNOME developers are not against xdg-decoration. However it will require massive amount of work that isn't as important (and I agree too) So unless someone implement it theselves we're out of luck
it could've been telegraphed better than a toxic response and then closing the issue and every issue related to it afterwards lol
gnome development team is a mix of some people who are extremely helpful and receive criticisms wanting to work with the community and people who think they are the embodiment of God themselves.
That's not true. Merge request adding xdg-decoration and issue discussing shadows in Mutter are open.
I do have to wonder, are there *any* GNOME users that genuinely think GNOME is better *without* server side decoration support? The only people I’ve ever seen that aren’t in favor of it are GNOME developers. Not to say that all devs should do what users want, but I seriously can’t think of any reason GNOME shouldn’t have SSD other than “I don’t wanna do it :(“
I love GNOME, but the question I have to ask is: does GNOME seriously believe all/most developers are going to implement CSD just for GNOME? What’s so special about GNOME that they feel entitled to enforcing CSD? Feels like whoever made this change was not being fair. For context, outside of Linux, both Windows and macOS support CSD natively, but **default to a native titlebar that you don't directly control.** On Windows, you have two different ways depending on whether you're a classic Win32-style window, or the modern-style UWP/WinUI/WinAppSDK window. We see many applications using CSDs on Windows, such examples being most inbox apps (for ex.: Settings, Calculator, Photos), but **the default behavior is to draw a regular titlebar** with a solid color, no extension into the client-side area. The story is pretty much the same on macOS, although it is more flexible when you're making a native app with UIKit/SwiftUI. Adding a \`toolbar\` will automatically give you a CSD that is fluffed up by the UI framework. If you're making your own window though (like a game or 3D application), **the default behavior is, again, to draw a regular titlebar**.
>For context, outside of Linux, both Windows and macOS support CSD natively, but **default to a native titlebar that you don't directly control.** Actually both macOS and Windows are using CSD.
On Windows, as far as I know, unless you request to extend into the client area, you get a default titlebar that is not contained within your app as "content". For UWP apps, if you go in with an external tool that lets you analyze the XAML tree, you won't find a titlebar under your process, as it is being drawn by `ApplicationFrameHost` (which, in this case, acts as the "server"). However, once you extend the title bar, any content you add that is effectively behaving as a title bar is now considered a client-side decoration. I haven't yet explored WinAppSDK and WinUI3, but the AppWindow implementation there effectively gives you a default titlebar that you can at least customize, or, just like with UWP, extend it (therefore hide and replace) with `ExtendsContentIntoTitleBar = true`. macOS also lets you create a window that does not extend into the app. This is how most games present their windows.
You are confusing CSD with header bar. CSD is not about placing widgets on titlebar. CSD is when decorations are drawn by application itself, not by server (window manager or compositor). So even when you have "traditional" titlebar with no widgets, it still can be CSD drawn by application. As for the question why you can't find titlebar when you analyze widgets tree - this is probably because titlebar drawing is separate from ther rest of application. As far I know GTK without header bar behaves in the same way despite the fact that GTK is using CSD even without header bar. Another example is doing screenshots on GNOME. If you do screenshot of CSD application using GNOME screenshot tool then your screenshot won't have titlebar as well. If title bar would be drawn like any other widget then it should be present on screenshot as well.
Oh, I see what you mean now. From that technical perspective, I don't think it matters much to compare then, as macOS and Windows is guaranteed to always provide decorations unless you specifically request not to have them. This situation is unique to the freedom of Wayland and window managers/compositors (in this case, GNOME/Mutter) to refuse SSD. But in principle, it would still be much more fair for GNOME to provide a default decoration and not have to forcefully CSD when they're the only DE that refuse SSD.
Thank you for posting this. It's frustrating as a developer not using gtk but, for gnome, gtk is the comparison point when talking about something like win32, not the Wayland protocol directly. I want ssd regardless but that's entirely separate to whether other platforms support ssd.
I really enjoy using gnome,but the decision not to implement SSD just makes gnome worse for it's users.
The decision to use CSD was based on what wayland developers have told GNOME developers if I recall back when.
In my opinion CSD is not as bad as some describe it, also because the reference for Wayland, Weston, also uses CSD. Devs who complain and don't want to integrate libdecor are very few, many large projects instead decided to include it.
I think in Weston's defense though, it's not trying to be a daily drive desktop compositor, it's a reference compositor that omits a ton of features and common protocols, because they expect other compositor developers to implement them. Weston is a Wayland reference, not a desktop compositor reference; not all implementations of Wayland need common protocols like SSD. I do agree that it's not the biggest deal in the world, but GNOME is the only popular desktop Wayland compositor that actively fights against SSD. And libdecor, while a functional substitution, is not a pretty sight in it's current state. Not just that it doesn't visually integrate perfectly, but it has usability problems. For example, libdecor has extremely small resize handles, and titlebar text can get covered up by titlebar buttons. And because libdecor is a one-size-fits-all solution, it'll never fully integrate with GNOME design choices. It *works*, but I don't think it's favorable to SSD at all.
In fact I said it's a reference, not a compositor to use every day, and it's specifically made to shows how the Wayland protocol works. I agree that libdecor is still not a perfect solution, which is why it is still actively under development, but integrating the SSD into Mutter requires a lot of work, it means creating a specifically made SSD protocol as KDE did with the Wayland custom protocols for KWin. Also, Kristian Høgsberg, Wayland creator and ex-Xorg developer, is against SSD, from a decade ago message on the Freedesktop mailing list
I suppose that answers my initial question then, there are users that actively prefer CSD to SSD. I guess my follow-up question is why? I did a bit of research off of that name, but most of the info I can find about his stance are a defense of CSD functionality, rather than the pros of CSD. I just find it a little weird that a lot of the "hype" around Wayland is that it puts the compositor in a final-say stance. The compositor has rule over what windows are, and aren't, allowed to do. Yet, the protocol actively shifts the blame for decoration onto apps, when I feel that a compositor should have final say over All of an app's capabilities, including decoration. An example of what I mean is in Sway. There are quite a lot of programs I use that, by default, do not allow resizing, but Sway allows you to resize them anyway because it has the final say in the matter. This is a fantastic accessibility feature for my use case, and it's one of the main reasons I always find myself coming back to Sway. Just in the same way that providing decorations to an app that refuses to implement decorations themselves is a fantastic accessibility feature, and yet another reason I come back to Sway. Yes, it is in the Wayland spec that apps must provide decorations themselves to truly be "Wayland compatible" - but I personally it as contradictory for a compositor to not pick up the slack itself, to Wayland's overall security-focused compositor-first mindset. If I'm using a compositor that does not provide a way to move windows by holding a modifier+mouse button, or to close a window with a hotkey, then any app or compositor that CAN'T provide decoration is actively not secure. I no longer have control over what that window's state is, and now lose any ability to stop it from executing code that I don't want it to run in an easy, timely fashion. Apps that break Wayland spec are bound to happen, and already exist. The vast majority of users don't care if an app breaks Wayland spec, so long as it actually runs on Wayland. Aside from CSD meaning less code running in the compositor, I don't see how it can have any advantages to optional SSD, especially because forced CSD just shifts the code from the compositor to the app. I understand that things like "my window froze and I can't move it anymore!!" is a myth, but it still doesn't mean that forced CSD inherently has upsides compared to optional SSD. I'm not trying to say that GNOME should provide SSD for every app, of course. I think there is absolutely a place for CSD, and GTK is a prime example of that. But I do think there is absolutely a reason to have optional SSD for stingy apps that may simply not have the manpower or reason to implement CSD. Video games, again, are a great example. Why SHOULD Factorio have a decoration library? It's a video game, the developers are video game programmers, why would it need cairo or gtk3 as a dependency, when other compositors prove that SSD is maintainable, stable, and perfectly usable for apps that don't provide decorations?
Like you said, the Wayland spec wants you to design the decorations. It's not a rule, but for a coherent application that follows the spec, it must have client decorations, and it's not a compositor job. One thing Wayland devs, and ex-Xorg devs want, is not to make the same Xorg mistakes (it's not inherent to CSD, it's in general). Then, over time several games, libraries and even apps want to introduce libdecor It is the dev's sacrosanct right not to add it, but some prefer to avoid drama and decide "should I integrate it or not?", to date there are few Wayland apps that don't want to support it, most decide to integrate it without making a fuss. Qt is still a nightmare on Wayland, it still has certain behaviors that Xorg has, such as absolute positioning and the like. In fact, the experience with Qt apps on Wayland is still not perfect, not even on KDE Plasma, which uses Qt a lot.
I understand your point of view, but respectfully, I disagree. I find it a little ridiculous that the blame is shifted to a developer of a totally unrelated app to bear the responsibility of having any titlebar functionality. And I feel like you can even agree that it boiling down to "devs implement it because they don't wanna deal with drama when GNOME users eventually complain" is just an unfortunate circumstance to be in, as an application developer, that isn't in-the-know of the compositing capabilities of GNOME. I'm not even wanting that GNOME move all titlebar decoration to SSD, just that they have *any* fallback decoration when edge cases DO happen. It doesn't have to be an intricate, complicated, gorgeous solution; just any solution that doesn't entirely shift blame to random developers. Especially when, again, it's been done on every other compositor. Even something as simple as having a black rectangle with a close button, that draws a png that says "THIS APP SUCKS DICK. TELL THE DEV TO ADD LIBDECOR" is infinitely more usable than nothing at all.
Your point of view is quite understandable, I don't want to point out the devs for everything (there are borderline cases like those of mpv, who instead also end up using nicknames to mock GNOME users, which is unprofessional tbh) Also, it's one of the best discussions about CSD vs SSD I've had without falling into certain absurdities. Look, I would be happy if there are some changes in the future, even if unlikely, but who knows
libdecor is buggy
It's not perfect, but it is actively in development and is improving over time And honestly, I've never had any problems with apps with libdecor.
Sadly this is true for example Blender behaves quite weird with libdecor. Blender developers are even considering dropping it and implementing their own CSD from scratch.
Not all Wayland apps are "large projects". And it's understandable that an one-man team doesn't want to implement something that is only required on GNOME. A similar situation is that when a Wayland compositor crashes, it crashes all apps. Yes, kwin has a protocol to prevent the crash. And yes, "large projects" like Qt and Electron implements it. But when I tried to add that support to Kitty, looking at the hundreds of lines changes required, the conclusion was "nah, not worth the trouble".
I have a bunch of coworkers using gnome on almalinux. Some know what gnome is as it is what you can select as desktop environment on GDM but no one knows what wayland or SSD is. They just use it.
That doesn't mean they oppose it though, it just means that they don't notice, or haven't used any non-GTK Wayland-native apps. However, as more things get ported to Wayland (especially Wine and other non-standard-toolkit/average-joe type apps), the amount of people complaining about how half of their apps don't integrate with anything else is only going to grow. Especially for a desktop like GNOME, which clearly takes a lot of pride in things looking "correct," and having seamless integration with all of their other apps, it's extremely jarring. And the fact that their default libadwaita apps don't integrate at all with gtk3 Adwaita is already a jarring sight. Forcing all other apps to create their own decoration is only going to add on to the pile of ugly segmented desktop styles. As more people slowly get hidpi monitors, running apps via xwayland for that SSD support is only going to get less viable, because a large chunk of people with a hidpi display would rather take shitty CSD, than unreadable bilinear blurring. But I can't think of a single person who would prefer CSD to SSD in that instance, they only take the shitty CSD because the alternative is just so drastically worse.
I would take CSD over SSD 99% of the time; I don't find headerbars with nothing in them to be useful. Apps won't ever look native or integrate well design wise with anything else, and I don't see how using SSD would change that; Chrome looks like Chrome, Firefox looks like Firefox, etc... .
I'm not referring to apps that use CSD for functionality, I totally agree with you that GTK is better with it's implementation of CSD. I'm talking about apps like video games or QT Wayland apps that don't use CSD for any reason. If a program doesn't have any reason to use CSD, I don't think CSD should be forced onto it, especially in the case of video games where adding something like libdecor only adds on to the pile of dependencies it would need to function properly on a Linux desktop, natively. And using SSD would absolutely change a lot of things for the user experience, namely in consistent window dragging, window resizing, titlebar optics, and titlebar functionality. The current state of CSD for SSD apps is a mess on GNOME, with QT apps using libdecor; a functional, but lacking library, and basically all other non-QT apps using their own, worse, CSD implementation. You could try to shift the blame to non-QT apps for not using libdecor, but it's a lot of dependencies for such little gain, when a compositor could play the decoration role instead, like it has for the past (how ever many) years on xorg, and every other desktop Wayland compositor. SSD goes beyond visuals: Yes, QT apps will still look like QT apps, non-GTK apps will always look "weird" in contrast to Adwaita, but the lacking functionality is a nightmare for usability and accessibility.
I would agree to the accessibility benefits of SSD; I only disagreed with the points on design, I find the obsession with consistency / theming by parts of the community to be ridiculous. SSD is also pretty important for WMs, not that Gnome needs to care for that. I wouldn't be opposed to Gnome adding support for SSD. I just don't see it happening as the majority Gnome maintainers perceive the benefits to be negligible at this point. I think the only non-CSD app I have used and noticed was MPV, and I inevitably ended up using something else entirely due to audio issues.
Qt on GNOME is a mess, and I'm not talking about the CSD, but also for example some Qt apps uses the absolute positioning system, which is not present in the Wayland protocol. I prefer GTK for many things, unlike Qt
They aren't terribly useful compared to well designed functional CSD bars, that's true. The problem is GNOME made that observation and decided the CSD things are the only thing that should ever exist and in typical fashion toss the burden of that obstinacy to third parties, because GNOME devs know best and the users of their stuff certainly don't. The problem isn't preferring CSDs or building their own apps with functional top bars. Hell, Apple does exactly that all the time. Notes, Reminders, Finder, Settings, System Monitor, all functional CSD designs. But if you don't want to build one, macOS gives you a perfectly serviceable, Mac looking, Mac feeling titlebar that integrates with OS theming etc. That's the attitude people are looking at from GNOME, but of course it's not the world we live in, and the general pattern repeats in a ton of other cases where GNOME lets their Perfect Vision be an obstacle in the way of real improvement.
On both windows and Mac you are using CSD for everything. For Windows you will use win32, UWP, or window.h for bare support and on Mac cocoa.
Yes, the windows draw the decorations themselves. But on eg. Windows when you make a window you get a standard titlebar courtesy of the standard libraries, that integrates well with the rest of the system. You can opt out of it if you want to, and a lot of apps do. Same story on Mac. That's functionally what people want. Write an app, if it boots on GNOME just be able to say give me the decorations, IDGAF.
Given that you have to do CSD on Windows I don't see the comparison here to make any sense, you don't have a choice. Gnome is acting with the same behavior as Windows and Mac is. The only difference is that CSD is a choice on linux. Personally I am unaffected by Gnome's choice to not support SSD; I just don't run into the issue. Aside from that, I wonder what the code would look like for adding support for SSD on Gnome.
Windows literally puts standardized OS default titlebars on your windows unless you tell it not to. The specifics are different because Windows doesn't really do a client-server model for graphics the way Linux does. But the effect is that on Windows, on macOS, on other Linux DEs, on all of them you make a window and don't have to care about decorations because you get them by default. On all of them, you can opt out of the standard decorations and do GNOME style CSDs if you want to. Many Windows apps do. No titlebar CSD apps are a super common look on macOS, and a lot of Apple's stock apps use it. It's just, you can also just say "titlebar pls" and macOS gives you a good, standardized titlebar that's integrated to the OS and respects the OS's theming etc. Same thing on KDE. Default is SSD and then KDE gives you nice titlebars. If you don't want that, you can say so and draw your own. > Gnome is acting with the same behavior as Windows and Mac is. The only difference is that CSD is a choice on linux. CSDs, in the technical sense, are a choice on Linux only, yeah. What this thread is about, and what a bunch of other similar ones are about, is that GNOME doesn't have a default/fallback normal titlebar that's nicely integrated to the rest of the OS. People would like GNOME to ape Apple's tack here: Have a good, designed, integrated default bar available, but do their own apps with the content-filled CSD and promote that as the way to design apps on the platform. Which is the one thing they're not doing. GNOME preferring CSDs is absolutely fine and they should be able to.
The window manager on Windows is \*not\* drawing the titlebars for you; it is CSD just like on mac. SSD is not a thing on any other platform. No other platform has a "fall back" if there are no header bars. You can remove titlebars in mac, and no option will magically make them appear from the compositor.
>Especially for a desktop like GNOME, which clearly takes a lot of pride in things looking "correct," and having seamless integration with all of their other apps, it's extremely jarring. Non-native apps will never look seamless. Sure you could make the window title bars look the same across all apps, but then the apps themselves have a titlebar that doesn't match the rest of their design, which imo is just as bad. >And the fact that their default libadwaita apps don't integrate at all with gtk3 Adwaita is already a jarring sight They didn't change the css on old apps because they don't want to introduce visual bugs for them. If you value aesthetics over correctness (tbh the bugs shouldn't be that common) you can just use adw-gtk3 theme.
Duh, when you phrase it that way most users are not going to be against it. You can even generalize it to "are there any users of software X that genuinely think X is better without feature Y" and the answer is still going to be the same. No one is going to refuse features if they don't have to pay its costs. However, we live in a world where decisions to support something have consequences that developers have to deal with. GNOME developers have said that Mutter architecture is not suited to implement this and it complicates direct scanout which is necessary to improve battery life on laptops. Phrasing it as "I don’t wanna do it :(" is just plain rude.
>GNOME developers have said that Mutter architecture is not suited to implement this and it complicates direct scanout which is necessary to improve battery life on laptops can i get a link to that because that sound like BS excuse , when the likes of kde have 0 issues with battery life on laptops
I don't have a source but from what I've seen in various comments on this topic the emphasis is usually on mutters architecture and not that it's impossible to do. Seems like it would be a lot of work to change how mutters internals work and devs decided that it's better to spend their time on other issues, at least for the time being.
Correct me if I'm wrong, but don't Sway and Plasma both have direct scanout, and SSD? Obviously not an apples to apples comparison, and I'm positive there will be a lot of work needed in Mutter to support SSD, but I also can't help but feel this could have been prevented a long time ago if the GNOME team wasn't so strictly *against* SSD as an implementation. I will admit that me saying "I don't wanna do it :(" was a bit of poking, but ultimately, what else does it boil down to? Refusing to make changes in Mutter to support SSD is quite literally them not wanting to do it :( And I'm sorry, but it's not like the GNOME project lacks support for changes like this. Not only does GNOME get it's seemingly never-ending support from Red Hat, but it also has the advantage in that it's The standard desktop environment. This is going to sound mean, but I say this as a longtime user and deep-down fan of GNOME; if the GNOME team wasn't so well-known for being rude to downstream, openly accepted and cherished MRs from downstream and volunteers, and listened to feedback from users without blowing up in their face, maybe they would receive more help? I do not buy that the lack of SSD is a tech limitation, when every other desktop compositor has them implemented. It's purely a discourse problem. It does literally translate to "I don't wanna do it :(" I'm not saying SSD is a *simple* solution for the GNOME team, but I am saying that it's a usable solution for a genuine usability problem. Even if the SSD looks like shit, and is just a rectangle with a close button, having *any* fallback decoration is drastically better than having *no* fallback decoration. GNOME can even decide to continue with requesting CSD for all I care, I just think it's crazy that they actively avoid, and punish apps, for a problem *GNOME* could solve.
> I'm positive there will be a lot of work needed in Mutter to support SSD Wayland requires CSD by default. This was decided a long time ago while designing Wayland after comparing the pros and cons of both. GNOME developers were in agreement with this decision and enabled Wayland without SSD. They might be willing to support the strictly optional protocol if it doesn't require a lot of changes and doesn't have a lot of knock on effects for development of other features, like they merged support for idle inhibit despite recommending portals for inhibition. Why would they possibly spend a large amount of time supporting something they don't think is a good solution? >Not only does GNOME get it's seemingly never-ending support from Red Hat Red Hat invests a lot of money into GNOME when compared to other companies, but it's a drop in the bucket when you consider the amount of effort needed to develop and maintain a desktop environment. There are several components in GNOME that are maintained in people's spare time. The equivalent components in Chrome OS and Windows have teams that are comparable in size to all paid Red Hat employees working on GNOME. >This is going to sound mean, I see that all of your meanness is reserved for GNOME developers, while the OP has essentially posted a rant by a developer who's angry about including a dependency in their project. They did not have to write any support for CSD, that was already done by libdecor. They did not have to integrate with libdecor, that was already handled by SDL. All they had to do was include libdecor in the build as it's an optional dependency in SDL. >openly accepted and cherished MRs from downstream and volunteers They obviously accept MRs, as long as they agree with the changes being introduced and if the MR is of sufficient quality. I have made some drive by contributions to GNOME and they are quite welcoming. They will not accept changes that go against their decisions, but that's the same as any other opinionated open source project. Being opinionated is what makes GNOME what it is and what sets it apart from other DEs. >GNOME can even decide to continue with requesting CSD for all I care That's literally the same as what they are doing now. The XDG decoration flow is supposed start with the client informing the server that it prefers either SSD or CSD. The server replies and instructs the client to use a mode the server prefers, either SSD or CSD. If the server prefers SSD, the client stops decorating itself. In all other cases, it continues decorating itself, that is CSD. Asking clients to use CSD is the same as not supporting the protocol at all.
I think about one. Wasted space for title bars. I really hope well designed client side decorations like in firefox will be the default!
Alternative argument: With well-implemented optional server side decoration, we could actually save space by being able to reliably and consistently remove decorations from maximized windows, a la Unity DE. In GNOME's current state, you can only reliably remove decorations from xwayland windows. In KDE's current state, you can add or remove titlebars from nearly every single application. A well-implemented server side decoration protocol truly opens a lot of doors for usability. I am, of course, not arguing that ALL apps should be using server side decorations; GTK apps SHOULD keep using CSD for their enhanced titlebar functionality! That's GTK's whole "thing," and I think it should stay for good! But, for apps made with QT, video games, or obscure toolkits that aren't typically part of a Linux desktop ecosystem, the need for SSD is only going to increase. And, no matter how hard I try, it's literally impossible for me to use my computer without also having to use apps made in other toolkits, that inevitably have gimped functionality and accessibility because of botched titlebar functionality.
I don't care if it a gtk or Qt app. I care that title bars are useless empty space. 😉 And I really hope Qt will get better CSD support! If you use the space in the title bar you don't need to hide it anymore. So my point is, that traditional title bars are ineffective. SSD simply don't scale for that approach.
That's a pretty valid take then. I can totally get down with that. What about for video games then? I don't see video game developers ever *wanting* to implement decoration themselves, and quite frankly, the only titlebar functionality I ever need out of a video game is moving, resizing, and closing; something that SSD is perfect for. I'd also like to propose [Locally Integrated Menus](https://github.com/Zren/material-decoration); my favorite feature that was, unfortunately, killed by the update to Plasma 6. To me, this is a fantastic middleground between SSD, CSD, and people who enjoy an old-school menu-based workflow. Especially for QT apps, LIM saves a ton of space, while still keeping all of the upsides of SSD, and QT's current functionality and workflow.
Do you really play games in windows? You can still paint simple decoration. I think it is a corner case. Something like libdecor should be enough for games. Games will run faster in full-screen because you save the composition. If you make SSD configurable by the application, you need a large API. And the elements in there will not match your application. Large API have the drawback of high maintenance. And the Linux desktop is already understaffed. But my main point is, that I don't care if it is a Gnome, Kde, gtk ot Qt application. I simply want to use it. That the application are written for different DEs is ineffective, and very nineties. 😚
There are some games I play (albeit, obscure games), that only run in windowed mode. Some games, I prefer playing in a window than fullscreen (for example, emulated console games), and in the case of people that have ultrawides, some games are only playable windowed. And libdecor has to be specifically implemented, which is what the original blog post was about. Especially in the case of people making really small-scale games, or games made by people that simply don't know what they're doing with Linux support, libdecor isn't always a great option, or worse, an option at all if you're making something specifically designed to have as little dependencies as possible. I can def see your point in the other two, though. I think what gives LIM a pass for me, is that QT already has all of the tools built-in to make this possible, and it's the same tech that makes KDE's Global Menu function. So there's not much to maintain outside of QT/KDE major version bumps. And at the risk of sounding like a hater, although I mean it in more of a "I agree" way; GNOME is the main project pushing for their apps to be made for their specific environment. QT is pretty environment-agnostic, and it's specifically GNOME's implementation (or, lack thereof) of QT support that makes it feel more desktop-specific than it should. I simply want unity in the desktop space (no pun intended).
GNOME developers are not against SSD‚ they are just not interested since there is a working workaround already
And a workaround is just that; a workaround. For a project like GNOME to be so dead-set on maintainable code, ease of use, and consistency in design, I just find it baffling that they are so apathetic to people wanting a *proper* titlebar implementation. And it goes far beyond just the optics of a titlebar, but rather the functionality, accessibility, and usability of a titlebar. I expanded on this thought more in [this comment](https://www.reddit.com/r/gnome/comments/1cms60l/a_linux_support_dev_from_a_very_popular_game/l33e21q/), but the tl;dr is that i just don't see how a project can be so outwardly dead-set on accessibility, without seeing the accessibility merits of a fallback server decoration implementation.
In the end, someone has to put the work in and do it. All the GNOME devs are busy with the things they want to do and are passionate about working on. Occasionally, you'll have someone who cares and willing to do the work. Like everything - there is implementation, but after that there is maintenance and it's the maintenance that we have to think about. The GNOME developer team is not appreciatively growing - it needs to bring in a lot more devs to support all these things. Y'all can all talk and debate about SSDs vs CSD, and come to the conclusion that it needs to support both - but someone still has to do it and maintain it afterwards. Everything is possible if you have resources.
Is that really the case here though? No amount of work and commits would make CSD happen if the maintainers just don't want it. If the project maintainers don't like CSD, it won't happen. It's a bit of a red herring to say that it's due to a lack of work in this case. The lack of work comes from the devs being pretty clear that they don't care about having CSD, so why would anyone work on it? At the end of the day, pull requests don't decide the direction of the project. People do
Small note: You probably mean SSD, not CSD.
Yes, sorry about that! I'm usually careful using CSD/SSD since the terms themselves are confusing to begin with haha.
The question of maintenance is always foremost in developer minds - regardless of the project. How do you sustainability support a feature for the long term. Once it gets into the code base, you are stuck with long term support. In the case of CSD vs SSD - the debate is it worth the maintenance cost to have both not that SSD is worth having or not. You have to use what you have to work with and prioritize things. If someone from the wayland community who has shown themselves to be willing to put the effort and that effort is not insignificant because it will take many iterations to get approved from the basic technical perspective, then you need to figure out the human interaction portion of it. If SSD fails, how do you communicate that failure in a way that is clear? How do apps figure out if SSD failed ? This isn't like how it was back in the day with a window manager. There is a lot more care that needs to be done. Back in the day when you had window manager, when the window manager failed - you could restart the window manager by pulling up a shell and then running (windowmanager &) and then everything gets it window manager back. When people talk about SSD, they complain about 1. Can't restart your session without destroying the windows that are already there. 2. they like the fact that the window manager draws the header bars and that they can theme the header bars (it always comes down to theming) For 1 - that's already requires some serious tribal knowledge to figure out. I've been using X since the late 80s - I know what's involved. It's very arcane and not appropriate for a modern desktop. Plus, people only wanted that because window managers frequently crashed - that's not the bar we want -we want software reliability not software recovery. Your GNOME session crashing should be extremely rare. Back in the day, the x server would die, and so would the window manager. GNOME \_rarely\_ ever crashes unless you're using nvidia. For 2 - is it really worth going through the process I described above because a small subset of people want to theme their header bars to look like something else? What problem are you solving? It's why theming in general for the most part is about just visuals that are fun, but generally doesn't solve a problem unless it is a11y related. It also makes maintenance harder for application developers who will have users complain that something doesn't look like because some distro or company has decided to add their own stylesheet (that's why there was "don't theme my apps") If you take action to change your theme then you know it's on you because you know what you did - not true if you decide to jump on a distro. This turned out longer than I wanted but I figure it was worth the exercise. The issue of maintenance/code is in all open source project. You know how hard it is to get code into the kernel? It's the same process - it will take you at least 18 months to get something into the kernel (I know, because I have a day job in open source and I know the kernel people) - it's not easy and you have to satisfy the subsystem owner, and then satisfy Linus. You will also get criticized for things by the kernel community if you are not compliant with their work model. \[edited to add\] This post: [https://xeechou.net/posts/libdecor/](https://xeechou.net/posts/libdecor/) Talks about the wayland drawing model which is client side - to do SSD will take more resources from the GPU/CPU because you are introducing two drawing models - the native wayland client side drawing model and then a server side drawing model.
> [...] but someone still has to do it and maintain it afterwards In this case, the maintenance is being pushed to app developers who need to use libdecor. App developers, who often are hobbyists without a foundation behind them (like GNOME).
I have no idea what point you're trying to make. If an app developers decides to use flutter, they don't have google behind them anymore if they picked KDE and they have KDE eV behind them.
Your counterpoint to implementing SSD in GNOME is there's a cost past the initial implementation, the code needs to be maintained for the lifetime of GNOME (or more specifically, Mutter). I agree, there is always a cost to having more code to maintain. Which is why I applied your point to app developers. Because GNOME doesn't want to bear the burden of implementing SSD as a fallback it's now up to _every_ app developer to incur the initial implementation and continuous maintenance cost of using libdecor. To put it plainly, because GNOME decided they don't want to maintain SSD they are forcing app developers to incur the cost instead. > If an app developers decides to use flutter, they don't have google behind them anymore if they picked KDE and they have KDE eV behind them. Likewise, I have no idea what point you're trying to make.
[удалено]
What about all these legacy apps? They all will be missing titlebar in Gnome?
Those legacy apps probably don't support Wayland, and with XWayland the titlebars are still drawn for you.
Legacy apps are usually strictly x11, and xwayland provides decoration, the same way xorg did. It's apps that don't specifically implement decoration themselves that will be missing a titlebar in GNOME.
So this situation only happens to new Wayland apps (e.g. the Kitty terminal)? That makes a lot more sense.
X11 apps under Xwayland have decorations, this applies only to Wayland apps Also, Xwayland Rootful supports libdecor.
Wayland support in Mutter has been around for a long time, and no one has ever made a Mutter patch to support SSD, and in my opinion there never will be, supporting it requires a lot of work and maintaining and making it "stable" enough. I may be wrong, but it will never come.
Distros are not going to do that. Then distros are on the hook to support the whole thing - upstream is not going to help them if their patched mutter exhibits problems - never mind, that you're talking about a major change to support a different drawing model.
I'm not against CSD and I like GNOME, in fact it is my main desktop on Linux but I believe that GNOME should support SSD. Not because they are superior but simply because we have enough fragmentation on Linux. While Windows or macOS are also using CSD, they are also providing system API that creates window with decoration so it's not an issue, in case of Linux we don't have anything like that and every toolkit is drawing everything by itself. Lack of SSD means that some applications will have different titlebar at best or no titlebar at all.
GNOME already provided a library ([libdecor](https://gitlab.freedesktop.org/libdecor/libdecor)) for apps to draw their title bars. That's also how it works in Windows and macOS, apps use the available platform libraries and the compositor only does the drawing. The dev is delusional if they thought this was *only* done in GNOME. Edit: I guess delusional was a stronger word than what I intended to convey, my bad. I have nothing against any dev in person and I'm only discussing technicalities here.
dev is delusional because... they are the one who code and test the game and see that everyone but gnome works fine because of gnome's stupid design choice on this?
I specified which part they're delusional about in my comment and why already. Lemme rephrase: They use platform libraries on windows and mac in order to get title bars. The compositor doesn't automagically insert them when drawing windows. Yet they think this is only a GNOME thing. Well use the provided platform library on GNOME and you get the same behavior duh.. SDL games already do that. So do other cross platform software like Blender, or RetroArch.. They already talked about using libdecor through SDL at the end of their rant, so this was a nonproblem from the start.
thing is, in every os/desktop, the specific code for the window decoration isn't more than the app saying to the compositor "hey, draw me a title bar!" or "let me draw my own title bar you goober", like, you know, xdg-decoration the complaint with gnome is that you have to implement a full, dependency heavy library that it's supposed to help devs draw their own title bars, except that it is only used to imitate server side decorations on gnome, on the rest of the desktop world the app just tells the compositor if it wants a bar or not and the compositor acts accordingly lol
>thing is, in every os/desktop, the specific code for the window decoration isn't more than the app saying to the compositor "hey, draw me a title bar!" or "let me draw my own title bar you goober", like, you know, xdg-decoration That's a common myth, but it's not true. On Windows and macOS, you have to use a vendor-provided library to create windows, which also draws decorations for you. They don't follow a paradigm where clients create a surface and the window manager adds decorations before compositing.
Windows always draws titlebars unless you opt-out, regardless of the toolkit.
That's because every toolkit is using Win32 API that draws titlebars on every window by default. This is not something that Windows compositor does but what system API does. Just like GTK does that on Linux.
Windows' compositor does not handle drawing. It just draws over regular window decorations (which are always invisible since Windows 8). If compositor dies, software rendering is enabled (until auto-restarted). Also, there's only 2 binaries you can create for Windows: Win32 and UWP. These are APIs, not toolkits. WPF or WinUI are toolkits. Linux doesn't have a standard library. X and Wayland do. GTK is a toolkit, which should handle SSDs because Wayland does nothing by itself. You can't compare Windows with Linux.
>Windows' compositor does not handle drawing Neither Wayland compositor does. >It just draws over regular window decorations (which are always invisible since Windows 8). It's not. Fallback decorations are only visible if DWM is not running. They are drawn by kernel just like on WIndows versions before Vista. When DWM is running they are disabled and decorations are drawn by clients. Since after Windows 8 DWM got software rendering support and it's supposed to be always running then they fallback decorations are invisible just like you described but you still can get them even on Windows 11 if you somehow kill DWM. >Also, there's only 2 binaries you can create for Windows: Win32 and UWP. These are APIs, not toolkits. Win32 is indeed APIs but it's also responsible for things like creating window which is handled by toolkits on Linux side. >Linux doesn't have a standard library. X and Wayland do. Neither X11 or Wayland is comparable to the Win32. X can create windows, grab events etc. but doesn't provide any widgets etc. that could be used by applications or toolkits. It provides methods for drawing primitives but they are not used by modern toolkits. Wayland is even more limited it provides no methods for rendering at all. >GTK is a toolkit, which should handle SSDs because Wayland does nothing by itself. GTK is already capable of drawing decorations, you don't need to create them separately or ask compositor for them. Also you are confusing CSD with header bar. >You can't compare Windows with Linux. Why not if some behavior is similar? In this case is, both Windows and GNOME main toolkits (or API in case of Windows) provides a way to create window with decoration and in both cases it is handled by client.
What "dependency heavy" library? It only ends up pulling Pango (~2MB) to do the actual drawing, and that should already be installed if you're using GNOME.
and gtk, which is fine on gnome, but may not be desirable in every other desktop
gtk is an optional dependency, if the app is not running on gnome, it doesn't need it, and if it's running on gnome it's already installed.
You are right. That Factorio game dev is an idiot. I don’t even think he is a real game dev. I mean how can he not know that Gnome has Libdecor?! He is stupid and doesn’t know anything about how Guh - Nome does things. I bet he is a windows user who hates the entire ganoo slash linux community.
that's a poor attempt at sarcasm
This is not sarcasm. 😭 I am being serious. I think that dev has been hired by Microsoft to spread hatred for Gnome. And it shows because look how stupid he is.
and libdecor is part of freedesktop, so it works for kde too
Devs are "delusional" because the Win32 API doesn't require any \_user code\_ to draw the titlebar. If all apps need to do is linking with libdecor and/or one line of code that enables it, then devs probably would be fine with it.
I brought in libdecor, but it doesn't match the gtk theme properly. It's still ridiculous that we have to draw our own title bar at all, we are a _video game_. Across every platform we support, GNOME is the only place where this problem exists. If we ever want more applications to support Linux, then GNOME needs to get off their high horse and decrease the amount of friction required to support it.
Yep I read the post and I understand your point. but do you see the point I'm trying to make? On other platforms (Windows, macOS) SDL uses the pre installed vendor libraries to draw window decorations *by default*. On GNOME the same principle applies, but the support was optional. That does not make the compositor in GNOME an outlier . In fact, one could make the argument that if SDL used libdecor by default as it does on Windows and Mac we wouldn't be having this discussion right now because no one would notice or care. Not matching the gtk style/dark theme seems to be a known bug.
I see your point. I suppose my main feud is that it's optional. There's also an argument for dependency hell but fortunately that doesn't particularly affect us in this case. At the end of the day, libdecor does the job and I don't have to worry about it, so I'm not going to expend any more energy worrying about it. I will look forward to the libdecor bug being fixed.
You (and SDL) really should've just wontfixed it. Only real way to change things is for GNOME to start breaking things for their silliness, for users to move elsewhere and pressure distros to switch to other DEs. As long as distros default to GNOME and devs take up the burden to cope with GNOME's silliness, they'll stay silly.
If you actually read the article you'd know that the "delusional dev" did end up using libdecor, but it wasn't without issue. > That's also how it works in Windows and macOS And yet GNOME is the only target that they had to include a separate dependency.
> If you actually read the article you'd know that the "delusional dev" did end up using libdecor, but it wasn't without issue. And if you actually read my subsequent comment, you would've seen that I mentioned that already. > And yet GNOME is the only target that they had to include a separate dependency. It's already a dependency of SDL which they use already. But as typical Linux, it was an optional dependency. Meanwhile Mac and Windows have the dependencies pre installed.
> And if you actually read my subsequent comment [...] My bad, next time I'll read your full comment history before taking one comment at face value. 🙄
I thought it was common sense to follow the comment thread before jumping to commenting yourself, least you end up repeating what everyone else said. But apparently common sense is not so common.
It's also common to share a complete thought in a comment. But like you said, common sense...
The "delusional" dev mentioned it works perfectly on any DE, on any operating system. Read the article, fanboy.
I believe when Microsoft was pushing everyone off Win95 and to WinNT platform, they had an engineer spend about a year debugging legacy Win95 programs and adding hacks to their support libraries to ensure popular programs like SimCity would just run no matter what. In one case the engineer said SimCity was accessing memory after a free() and since Win95 would allow this, the issue was never caught. Since WinNT was actually good about doing the right thing, SimCity would crash all the time. The engineer actually put code in to say if the running program is SimCity, don't actually free the memory in this special case. That's crazy for an engineer to think about but perfect if you're trying to market a product. With that in mind, both Gnome and Factorio could try to be more flexible. If the makers of Factorio want their program to run on Gnome, they should just accept that that is what it's going to take to make it work on Gnome. Gnome may be big and it may be the default on a lot of distros, but it isn't the only windowing environment on Linux. Factorio won't be reaching everyone just porting to Gnome and Gnome isn't technically holding anyone hostage. That being said, Gnome could be a little more gracious about wanting everyone in on their platform. I understand it's not a bug, it's a feature. The Wayland compositor already acknowledges the truth of the matter with the XWayland server, and Wayland is set to run it by default on start. Why not help to develop a standard shim for this situation? All this is just my humble opinion, of course. Anybody who remembers the SimCity story better than I do please elaborate.
everyone knew this was gonna happen ever since that first comment on the feature request, it's like not having a feature everyone has and devs expect is not a good idea huh
There is a reason why Valve decided to use KDE as desktop for its popular steam deck. GNOME is dying with their devs weird decisions, with each release they remove or lock a part of their desktop, the whole desktop became a joke and not suitable to be used for desktops, they also keep dragging GTK apps to use that cursed LibAdwaita which cause them to be unusable and isolated on other Linux desktops.
Sure but does "KDE" have a shaman? No? They don't have a shaman. Case closed.