> Both win32 and macos draw decorations client-side.
That's technically true but misleading. Yes, they have client-side decorations, but also a single and unified UI toolkit all applications use. So effectively _you_, the application writer, do not have to care about decorations.
Whereas, on Linux Wayland, if you want to support GNOME, _you_ have to care about decorations, or you have no titlebar nor X button. Which means you need to link against libdecor yourself to get that functionality and in theory wouldn't be that bad if that library was maintained and functional, but it isn't. The one stable tag is 0.1.0 from one year ago, and it still causes massive lag when trying to resize a window if you have more than 1x scaling: https://gitlab.gnome.org/jadahl/libdecor/-/issues/37 — Don't be mislead by the title, affects AMD as well.
libdecor is the _only_ way to have decorations on Wayland on all major DEs, unless you actually want to write the entire decoration code yourself. And it's buggy and unmaintained. And, cherry on top, libdecor does not match the desktop environment's look and feel, so your app has decorations that look completely out of place.
I'm a GNOME and Wayland apologist, but libdecor is terrible, unavoidable, and exists only because GNOME couldn't pull their head out of their arse and created this situation.
Not supporting server-side decorations is only a good idea in a vacuum, not in the real world. Applications should be able to choose whether they care about it (i.e. Firefox for their UI), or not at all (i.e. a video game window), as it's possible to do in Windows or macOS.
> Yes, they have client-side decorations, but also a single and unified UI toolkit all applications use.
MacOS has Carbon and Cocoa (and WebKit). QuartzCore lets you make windows, but doesn't give you decorations. Pretty similar to libwayland.
Windows has Win32 and while it does provide window decorations new UWP apps and thus the rather long list of various UI toolkits made by microsoft provide their own decorations. This is why dark mode doesn't work on some apps. So the situation is again pretty similar to libwayland.
Window decorations aren't even the same for different versions of Windows/macOS, so if you want to implement your own you'll end up providing multiple implementations for each platform.
The real difference is that there's a single entity with the will to go through each and every UI toolkit and update them all to look the same ahead of a new major version. That's not to say that server-side decorations are therefore bad; it's just that Microsoft and Apple put the resources behind client-side decorations to make them work as well as they do.
> MacOS has Carbon and Cocoa (and WebKit). QuartzCore lets you make windows, but doesn't give you decorations. Pretty similar to libwayland.
Carbon was deprecated well over a decade ago, and has not been available for several iterations of macOS.
> The real difference is that there's a single entity with the will to go through each and every UI toolkit
No, the real difference is that it is absolutely clear on macOS and Windows what the obvious/preferred/blessed UI toolkit is, and anyone who chooses to use something else is extremely aware of the consequences of that (and if they weren't before making that choice, they will be very soon afterwards).
On Linux, the situation is more or less the opposite. Not only do you have the choice of actual UI toolkit libraries, with none being more or less "blessed" than any other, but with Wayland's adoption, the fundamental windowing technology that sits on top of the video drivers is also not a single thing either.
Apple certainly seem to think that WebKit is at least a partial alternative to Cocoa, given their use of it in parts of the system preferences. Apple is keeping those two in sync so things don't look out of place.
Microsoft has widgets in WinAPI, and then there's WinForms, WPF, WinUI, WinJS and don't forget Electron which Microsoft themselves also ship apps with. There's also the whole win32 & UWP distinction. If you dig deep enough into the system settings you'll even find Dialogs that use the wrong window decorations.
In the last year-ish I wrote a pure-Rust windowing and input library for Windows / MacOS.
I never even had to think about making the window controls appear, they were just there by default when I created a window.
If I eventually want to extend support to Wayland / Gnome I need to figure out how to pull in complex UI framework dependencies. Or I could write my own code to render window controls but it won't be a perfect match to the platform's aesthetic. Compared to Windows / MacOS it's a mess.
Unless you only used QuartzCore on macOS and asked win32 for no decorations you've also pulled in a complex UI framework dependency on Windows and macOS. I agree it's a mess, but not because things work on macOS and Windows without complex UI frameworks.
On MacOS "pulling in complex UI framework" amounts to "#[link(name = "AppKit", kind = "framework")]" somewhere in my Rust codebase. On Windows it's similar.
With Gnome it seems unclear how to do something equally simple to get decorations that match the OS look and feel. The most popular Rust windowing library ended up implementing their own client-side decorations rendering that imitates GTK: https://github.com/rust-windowing/winit/pull/2263.
And if every framework / app is doing this in their own subtly different way then the result is an OS where many apps have slightly different UX, buttons, text rendering, shadows, etc. A horribly unpolished experience.
This post is a nice case study why the year of desktop Linux is unlikely to happen any time soon, or didn’t happen in the past.
It takes large engineering work to write all the software, and needs discipline and people working on very boring areas and aspects of the UI. I find it unlikely any OSS community will ever pull it off, unless there is a clear monetary incentive to fund it and work hard.
There is no reason to think it can't be pulled off, but the Linux world suffers from catastrophic amounts of bike shedding.
The Linux desktop needs a leader figure. A Steve Jobs, or a Linus Torvalds.
Leave it to the community, and everybody wants to reinvent the wheel and paint it their favourite colour. Directed innovation can only be achieved from a single vantage point, not by a committee, let alone a ragtag of independent actors.
How did Linus convince hordes of people of contributing to his kernel, his trademark, for free? The official repo is under his personal account at github.com/torvalds/linux
And regular for profit companies aren't incompatible with Linux. Canonical, Red Hat, etc. make billions from open source.
Let me stress this again: the only reason the Linux desktop sucks is organizational. Not monetary, not technological. Linux would be a niche project today if Linus had been replaced by a committee or other loose organization. The Linux kernel is successful because there is a person at the top saying "No."
The Linux desktop has no such thing. None of the singular desktop environment have such a thing. GNOME has no BDFL, nor does KDE. So its endless bikeshedding and churning and going nowhere.
Point is, it's Linus that merges what he wants in his tree. The kernel development isn't a democratic process, not everything has to be. Everybody can fork it and be the big boss themselves, the fact that nobody and no company has succeeded in doing so is worth thinking about.
Yeah, and the thing about forking is, it's not that it shouldn't be done, but it should be done in an organized way- too much forking and you could have many people interested in a common alternative, but not enough coordination to pull it off. https://cmustrudel.github.io/papers/fse19forks.pdf "What the Fork: A Study of Inefficient and Efficient
Forking Practices in Social Coding" 2019
> How did Linus convince hordes of people of contributing to his kernel, his trademark, for free?
You will find -- unsurprisingly -- that most of them are not contributing for free.
That's not to say there aren't people contributing code written in their spare time. I'm one of them (but not completely: there's stuff I wrote on my own, and submitted in my own name, and also a bunch of stuff I wrote on the job). But the vast majority of people contributing critical code are not doing it for free, and haven't been doing it for free for a very, very long time. Unpaid contributions are the exception, rather than the norm.
> You will find -- unsurprisingly -- that most of them are not contributing for free.
How does that invalidate my point? GP asked why people would contribute to leader-directed open source without coercion. I just pointed out no coercion is needed. Free or paid is irrelevant.
> How do you propose that people work *for free* at the behest of a leader directing such unpaid contributors how to o their work?
(Emphasis mine)
No coercion is involved, but they don't work for free, either. Free vs. paid is extremely relevant. If you were to strip out the paid contributions from the driver tree, for example, you'd be left with a handful of drivers, virtually none of which cover non-trivial devices released in the last fifteen years or so with anything near full functionality.
> You will find -- unsurprisingly -- that most of them are not contributing for free.
Is that a meaningful distinction? I don't think the point was that the people actually writing the code aren't paid, but rather it still holds when you consider that the people paying them choose to allocate those efforts to a dictatorial organization rather than addressing their goals in some other way.
> How did Linus convince hordes of people of contributing to his kernel, his trademark, for free?
Right confluence of factors to a large extent. GNU needed a kernel, and BSD was mired in legal trouble. Linux was there at the right time to provide a GNU-friendly kernel made from scratch.
I think the GPL was also a fortunate choice. It ensured large companies couldn't easily have a closed in-house version and had incentives to contribute to the common good.
Lamentably I think you are right. Although to be fair I'm using linux as my daily driver and it works great (PopOS X11 still...) Though I fear adding extra confusion to writing desktop linux apps isn't going to help things get better.
I would like to write some applications for linux when my work life ends, but there seems to be a dozen different ways to do it. A ton of choices to make I don't fully understand, but I really don't want to have to know the nuances of the windowing system to be able to write something that works well with KDE and Gnome, Qt, GTK and whatever else one needs to know about compositors... A lot of stuff is web based now and linux handles that great, but desktop apps still have a place.
I feel like sometimes being the "best" platform doesn't matter so much as being able to target most distros with less work would help the ecosystem a ton. Using Linux as my daily driver so hope springs eternal.
FWIW, if you use Qt, your app will look and work good pretty much everywhere, excepting if you want to integrate deeply with the shell. But for most apps it's not an issue.
I'm optimistic and hopeful regarding newer GTK. It seems to be modernizing nicely, though I haven't actually written an app in it yet.
If I could wish for one thing for Linux though, it would be a great toolkit to target it that also makes distribution a breeze. That it is still an unsolved problem causes me pain.
It affects anything which put any sort of strain on the compositor. A hi poll-rate mouse also trigger the issue simply because there will be more resize events. Why gnome-shell doesn't apply some sort of back-pressure or opportunistic skipping of events when it is behind is beyond my understanding.
Well, I get at least six different cursor sizes depending on the window hovered. Sample apps with rough eyeballed scales: Firefox gets 1×, XWayland gets 1.5×, Alacritty 2×, Sway 2.5×, Zeal 4×, and I can’t remember what the app was that had something else again…
Probably some ubuntu fuckery. I have Firefox in a container as well (but it's Flatpak) on Fedora, and it uses the same cursor as the rest of the system.
> Whereas, on Linux Wayland, if you want to support GNOME
If you want to support GNOME, you use GTK or use a library that interfaces with GTK.
The binary compatibility with other desktops is just a "nice thing" to have, but GNOME really doesn't care for apps not made for GNOME.
There was a project where Qt would interface with GTK and let GTK handle its window management (similar to macOS/Windows), rather than dealing directly to the display server, but I think its dead.
But there is a great difference between not caring and sabotage.
Not caring is passive neglect, maybe not nice, yes. But sabotage is activly disturbing something with evil intentions. So this is a strong accusation, for which I like to see some more solid evidence, to believe it.
It’s the co-opting of GTK that drives that. GTK used to be fairly platform-neutral under Linux, and at least moderately neutral on other operating systems, adopting some of their conventions and with theme matching being possible. It has become increasingly aggressively GNOME-bound, so that with every major release it becomes more and more difficult to produce anything that looks or feels native on any platform other than GNOME. (Even under Linux; and it’s completely impossible to produce a good result for Windows any more.) Gutting theming. All but forcing a particular idiosyncratic form of overlay scrollbars. Insisting on client-side decorations and refusing almost to acknowledge the very existence of server-side decorations (in both GNOME Shell and GTK, from both ends). The list goes on, though these are probably the three biggest ones. From time to time they take a small step back (e.g. libadwaita) or present an apparent alternative (e.g. libdecor), but those options never work well, and I strongly suspect that, whether consciously or unconsciously, they’re just to try to placate the mobs. (libadwaita hasn’t gone anywhere near far enough, to the point where they might as well not have bothered: GTK is still riddled with mandatory GNOME HIG stuff that is strongly opposed to conventions on other platforms.)
’Tis said: never attribute to malice what can be adequately explained by incompetence.
But malice learns to wear incompetence as a mask, and organisations weaponsise incompetence.
I doubt that individual GNOME developers mean any malice. There may be no malice intended from any of the GNOME project leaders. But over the last few years I have steadily become convinced that cumulatively their actions and policies are active sabotage towards every last bit of the Linux desktop that isn’t GNOME.
See also what they did to Gtk3 in 2014-2015, removing a bunch of features, stopping respecting gsettings, making it so that it is impossible to paste a file path into a file-open dialog without triggering an error (you must first do an extra key sequence just to make the filepath box appear now).
They acknowledge that these are serious bugs but no one is willing to take on gtkfilechooserwidget.c anymore to fix it. So all filechoosers in gtk have been frozen broken since that time.
But GNOME/Redhat employees don't care. They switched to Gtk4 (where these bugs are fixed). All the programs depending on gtk3 can just rot according to them.
It’s funny to hear positive speech of GTK 4, though, because apart from the accessibility stuff (once it’s all finally hooked up) I don’t think I’ve heard a single positive thing about it, but only more discussion of things they’ve gutted and broken for non-GNOME environments (… including font rendering especially in Flatpak or whatever), and my experience from trying out rnote and gtk4-demo under Sway has not impressed me either—just more badly-forced CSD, new slow and poorly-designed animations (most notably focus, but also things like caret blink fading), and traditional menus are super ugly and apparently completely broken by keyboard (gtk4-demo; run the Builder demo; press Alt+F to open the File menu; marvel first at how access keys are no longer underlined until you further press Up/Down, clearly a bug; leave the menu by keyboard, either by activating an item or by pressing Escape; observe that now the keyboard does absolutely nothing of any sort until you click in the window again).
(And it’s easy finding more super obvious usability bugs. Compare the keyboard usability of the colour picker in the Pickers demo between gtk3-demo and gtk4-demo: they both get initial focus wrong, by keeping the Cancel/Select button focused if you clicked them and are reopening, but beyond that gtk3-demo is fine, while the gtk4-demo one has the wrong button as the default action when you press Space or Enter on an already-selected colour: it should obviously activate Select, but actually activates the Custom “+” button and then focuses the Cancel button. That suggests they’re modelling form controls in a somewhat weird way and made a fundamental change to the handling which will be responsible for bugs in a variety of similar places. And I can’t even be bothered filing any of this, but if anyone else wants to, feel free.)
I may have worded it a little strongly (despite tempering it with the word “almost”), but hear me out.
GTK will use SSD so long as you don’t customise the title bar. I think you can even query it, with effort (gdk_wayland_display_prefers_ssd, c.f. https://gitlab.gnome.org/GNOME/gtk/-/commit/f2adaba237519642...), and thus behave differently depending on compositor preference. (But even that is mildly nerfed from the org_kde_kwin_server_decoration_manager interface, since it only exposes “prefers SSD” and not “supports SSD”—though in practice I suspect there’s no difference in any compositor.)
But guess what? GTK 4 has regressed matters in this space. Fancy that. If I run gtk3-demo, as a tiled window it gets Sway SSD and an app header bar which duplicates the title (fine), but it doesn’t have the window border or shadow (good). When I float the window, it gets border (including top radii) and shadow. This is well-behaved software, not acting quite how I’d prefer it to (I want SSD even floating, even double-title-barring), but still reasonably. But gtk4-demo? It gets border and shadow (drawing outside its designated area even in tiling mode, and I’m not sure why it’s possible for it to do that) regardless of whether it’s floating or not. Progress. They’re forging ahead with ignoring the existence of SSD as far as possible even in GTK.
I just tested running gtk3-demo and gtk4-demo in sway. gtk4-demo does draw its shadows on other windows, but I wouldn't have noticed that if you hadn't brought it to my attention. Each has only the GTK title bar (no sway title bar) in both floating and tiled mode (but not full screen), which is, imo, a reasonable way for things to work.
Not sure how you’re getting no Sway title bar out of it. In fact, when I run `swaymsg border csd` with the tiled gtk4-demo focused, I get “This window doesn't support client side decorations” and I have no idea what’s up with that, especially given that the window definitely gets border csd when floating. ¯\_(ツ)_/¯
It’s possible it’s related to more recent changes in Sway. I haven’t updated Sway since March (since I’ve been using the high-DPI XWayland patches and updating is comparatively bothersome). I dunno.
Incidentally, I mostly use tabbed layout, and you’re always going to get server-side decorations out of that, since you’re breaking out of the rectangles mould.
Rhel 8 still allows x11 as an option, does that mean it won't be getting gnome updates? My business has decided to keep x11 for the foreseeable future. I don't mind at all, I use x forwarding a lot.
GNOME lifecycles in RHEL differ from other, leading-edge distributions. GNOME rebases aren't just simple API/ABI compatible minor updates, and things can break in doing so, therefore RHEL engineering wants to do them sparingly. Granted with GNOME 3.x there were quite a few rebases in RHEL 7 and RHEL 8 to fix issues and growing pains. Feature and fix backports are the preferred method for updating GNOME in RHEL, rather than complete rebases.
The Xorg Server has been deprecated in RHEL, but exists in both RHEL 8 and RHEL 9 and will be maintained in those distributions for the entirety of their lifespans. It will be removed in some future version of RHEL. X11 support is provided by XWayland.
"I doubt that individual GNOME developers mean any malice. There may be no malice intended from any of the GNOME project leaders. But over the last few years I have steadily become convinced that cumulatively their actions and policies are active sabotage towards every last bit of the Linux desktop that isn’t GNOME."
How?
I use XFCE and I do not develope native linux apps, so I lack detail knowledge here - but as far as I understands it, GTK is developed for GNOME. It has even Gnome in the name. So of course they mainly care about - well, GNOME.
So knowing this, I simply would never choose GTk as a plattform for my software, if I would not intend to have it mainly in the GNOME universe.
(I would probably use something like Qt, which is explicitely not advertised as bound to one Desktop, but right now I rather stay with the WEB and avoid all of that).)
I mean, did GTK advertise itself as a universal linux toolkit and promised eternal support at some point? Then there might be a point of them being assholes, but even then it would not be sabotage, if they simply focus on their priorities.
It would be entirely something else, if the company Redhat would do all the changes by purpose to break other stuff to make people switch to Gnome. This would warrant the term sabotage - but the evidence I have seen so far is not convincing.
So maybe it rather was people using GTK because it worked "fairly platform-neutral" and then expected it stays that way? And then got mad, when developement direction changed?
So making demands of something they got for free?
Like I said, it might be free, but I do not intend to be bound to gnome(and I do not like GTK too much) so I will never use it for my apps. And people who did, probably have to switch - or fork it and adopt it to their needs.
Good points, I was not aware of that anymore. But I think my broader point still stands, even though I just checked the GTK website and would agree, that they could probably make it clearer, that they primarily focus on Gnome. Still, Sabotage is a strong word.
This is exactly why I’m calling it co-opting and sabotage. GTK used to be capable of being even fairly OS-neutral, and was certainly quite neutral within Linux and so became the widget toolkit of choice for diverse desktop environments and worked well thus; but over time GNOME has taken it over completely, and the desires of other desktop environments are utterly ignored. The GNOME Foundation has become a very, very bad custodian for GTK.
This is a valid take, but it further fragments the Linux desktop. There are already too many different standards and technologies and transitions going on. Some of them for good reasons admittedly. Desktops only being compatible with their closely aligned toolkit is the last thing we need.
> Whereas, on Linux Wayland, if you want to support GNOME, _you_ have to care about decorations, or you have no titlebar nor X button
And you have basically two UI toolkits for linux that also does everything for you without caring about it, how is that different? Also, if you do decide against using said frameworks, you also have to care about accessibility and a million other things that you weren’t going to do either way let’s be honest, so I don’t know, it seems to be a non-issue to me.
Use libraries instead of reimplementing everything from scratch.
Sure, but then it is the job of those framework developers to.. abstract away the underlying display manager, so they should port their framework to support wayland as well, and application devs can just continue to write against this abstraction. I still see no problem here.
Those others - for better and worse have less developers. Having to figure out two different types of decorations is a mess that they don't have time to, so I can't blame them for picking one.
That is inherent in open-source/bazaar-style development, and we can all help wherever we can. There is no entity like Apple/Microsoft mandating that we change to Y from X.
That's impressive, but being an optional install and not even available on most distros doesn't really make it a useful target for applications that just want to show some window decorations. I also doubt that Debian have ported GTK 2 to Wayland or added client side decorations to GTK 2 so its even less useful in the context of this discussion.
New applications would not target GTK 2, obviously. But that's not what you asked.
GTK 2 was EOL'ed many years ago, and hence will never have Wayland support nor CSD. But there are dozens of existing applications in Debian's repos that still use it.
Wayland is going to have an X server for the foreseeable future, because otherwise the overwhelming majority of GUI applications for Linux will not run there.
That's technically true but misleading. Yes, they have client-side decorations, but also a single and unified UI toolkit all applications use. So effectively _you_, the application writer, do not have to care about decorations.
Whereas, on Linux Wayland, if you want to support GNOME, _you_ have to care about decorations, or you have no titlebar nor X button. Which means you need to link against libdecor yourself to get that functionality and in theory wouldn't be that bad if that library was maintained and functional, but it isn't. The one stable tag is 0.1.0 from one year ago, and it still causes massive lag when trying to resize a window if you have more than 1x scaling: https://gitlab.gnome.org/jadahl/libdecor/-/issues/37 — Don't be mislead by the title, affects AMD as well.
libdecor is the _only_ way to have decorations on Wayland on all major DEs, unless you actually want to write the entire decoration code yourself. And it's buggy and unmaintained. And, cherry on top, libdecor does not match the desktop environment's look and feel, so your app has decorations that look completely out of place.
I'm a GNOME and Wayland apologist, but libdecor is terrible, unavoidable, and exists only because GNOME couldn't pull their head out of their arse and created this situation.
Not supporting server-side decorations is only a good idea in a vacuum, not in the real world. Applications should be able to choose whether they care about it (i.e. Firefox for their UI), or not at all (i.e. a video game window), as it's possible to do in Windows or macOS.