The article essentially says--whether this is a good idea or not--that GTK is the one hold-out, which I wasn't really expecting as a punchline; why is GTK not implementing this?
It's a wholly expected punchline to anything wayland: by most accounts Gnome is one of the worst offenders in the death-by-comittee wasteland that is standardising protocols in wayland.
Maybe it can be found under other terms of course, but all I'm saying is, before picking up the pitchforks, maybe it'd be worth asking if they'd just accept an MR. Yes, I know many (myself included) are not thrilled with GNOME's approach to Wayland, but it's not going to be any more productive to just assume bad faith, at some point you just gotta push forward.
If GNOME does anything I personally don’t like it’s usually the result of a grand conspiracy by Red Hat to make the Linux desktop worse, increasing their consulting profits. (/s)
> grand conspiracy by Red Hat to make the Linux desktop worse, increasing their consulting profits. (/s)
I must admit, I have wondered about the plausibility of this in the past. It seems like ironically, making a problem-free Linux would be a conflict of interest to Redhat, which makes more money the more problems it has.
Is there any particular reason you think it couldn't be the case? I could definitely see it within the realm of possibility, especially since they maintain a huge chunk of the ecosystem nowadays (Fedora/RHEL, GNOME, LibInput, Kernel development, NetworkManager, Pulseaudio/Pipewire, Systemd, Wayland, and probably even more in the future.)
Because just factually Red Hat isn't working on many of these things alone. Most of these project have huge interest from many parties. And all those parties work daily with Red Hat and somehow the conspiracy remains undetected. The idea tat Red Hat corporate overlords can easily hurd the Gnome developers just isn't how the project is set up.
Many of the contributes to these project, even when being employed by Red Hat don't always do this as their primary job, many do it because they want to. It just so happens many people that love the linux ecosystem and linux itself work at Red Hat.
Other then that, many project that are very unifying and don't create much 'conflict' are also lead or worked on by Red Hat people. Pipewire for example has been the opposite of 'conflict' for the most part. LVFS is another good example. Flatpak/Flathub are another great example (Maybe Ubuntu is the evil agent of chaos). Systemd is also almost universally adopted by ever major distro even if it created much conflict.
Somehow people can't decide if Red Had is an evil dictator wanting to control everything or if they are deliberately creating 'conflict' so nobody is in control.
The simple reality is, there are a huge amount of people with incredibly different opinions in the Linux space. Even different people employed by Red Hat also don't always agree with each other. So who is really the true Red Hat conspiracy agent?
Difference on opinion is fine as long as people work on their own stuff, but when it comes to unification, like Wayland protocols it just gets really hard. The reason there is KDE and Gnome is because of fundamental disagreements about goals and that will be reflected in how they think wayland properties should be installed.
P.S:
> making a problem-free Linux would be a conflict of interest to Redhat, which makes more money the more problems it has.
What is your actual evidence for this statement? If that was true, why are they working on all those projects. Objectively things like Pipewire, LVFS, Flatpak, Systemd have been major improvements to the ecosystem.
Gnome and Wayland (among other things) are the way they are, in part, to make running anything other than a standard-package-selection Red Hat unappealing to folks who might pay for Linux (enterprise). It’s good for them if their stuff’s a bit broken if you use other distros, or configs/software they don’t want to support, and if they cause integration pain and extra work for other distros.
Or if that’s not the reason, the behaviors of a lot of projects RH birthed or heavily influence make a whole lot more sense if you assume it is and are fairly lacking in explanation otherwise. If it’s not the case, they’ve managed to accidentally do something that’s in their interest, I guess.
I think it's just a standard corporate insularness. Devs being paid to work on the software by the corporation view outsiders as a nuisance and certainly don't like outsiders giving them more work to do. They'd rather find justifications to remove features reinvent old systems to "reduce legacy cruft" (make their jobs easier.). Basically, it all makes sense if you assume standard commercial developer motivations.
Fornunately with Free software that doesn't matter too much because anyone can add a feature and if you don't want to accept it people can go to the other person's implementation instead.
I mean, isn't that how Cinnamon and Panteon and Unity and Cosmic and MATE were born?
It's a great strategy for sure. If I were running a software company that depended on software licenses and consulting fees for income, and I had to keep my stuff open-source, then what you outlined would be the best (and really, only) strategy for long-term survivability. It's a moat, and a good one, because it's plausibly deniable.
So why don't people just stop caring what gnome thinks? Can't they just standardize the stuff regardless of gnome "holding out" on them or whatever it is they're doing? Do they need their permission or something? Just leave gnome behind. Doesn't really matter whether they catch up or not.
> So why don't people just stop caring what gnome thinks?
Because Gnome is RedHat and ...
1) Because RedHat is one of the few companies that puts sustained, long-term funding beind developers working on Linux. As such, they get an outsized say in what goes on because they are doing the work. If you would rather that Linux go a different direction, fund a bunch of programmers and take it that way.
2) RedHat put in the work, time, and money to get certified in ways that allows it to be used for big business. That means adhering to things like accessibility, auditing, etc. If you get the same certifications, big business accounts can use your stuff instead.
If you want people to ignore Gnome, all you have to do is fund a bunch of Linux developers to do all the work they are doing. Easy peasy.
Well to me it sounds like a lot of other people also put in time and effort into making Wayland better, only to be consistently blocked by gnome/redhat at every turn.
It's not the first time I see people air their grievances like that so I gotta wonder why people keep working with them. Let red hat pay the developers to take Linux in whatever direction it wants. Other developers can go in some other direction that they agree with. The beauty of Linux is the kernel enables such a diverse user space. That's what I personally care about.
gnome folks are on the committees just like everybody else is. They don't have veto power in that way over the accepted standards, only in what they implement.
They actually do that. Consensus is a goal. But if it can not be achieved then at some point people will just create a protocol anyway, even if Gnome doesn't implement it. People who claim this isn't the case haven't actually followed the space at all.
Of course issues still get stalled on this, because it takes a while to figure out that the disagreement is to fundamental. Often a compromise is actually found in the end.
Ah we are rolling out the old Red Hat conspiracy nonsense again. Classic HN.
I'm sure that why they invested in Flatpak, they just really want it to make it impossible for people to run non-standard packages on Red Hat. Makes total sense.
That isn't really surprising to anyone who has been following how GNOME approaches wayland.
GNOME is also the one holdout that doesn't support server-side rendering of window decorations (like the title bar with buttons to close and minimize).
GNOME has pushed back on several wayland protocol extensions that all the other compositors supported.
They did that for a reason. Rendering decorations server-side is a really bad idea. Just because X11 did it is not a reason to repeat the mistake.
If other compositors want to do it, they have their optional extension for that. Eventually, they will find out why they shouldn't do it. With mandatory extension, there would be no way back, with optional, there is.
I've yet to see a good argument for why it's a bad idea. To me client-side decorations are mostly yet another way that the desktop is turning into a cluttered mess of different UI styles.
1) Synchronization: when you are rendering decorations in a different process that the window content, you never get frame perfect. You can't synchronize both processes for each frame.
2) When painting using two processes, you need two surfaces. You just doubled your VRAM usage and the amount of blitting you need to do.
Now, decorations are not only the window chrome itself, but parts of them are font rendering (Qt renders fonts a little bit differently than Gtk, you can see the differences) and popup menus (when right clicking on the window chrome). The menus are a difficult thing; they basically pull in the entire respective UI framework (theming, sizing, font rendering, ...). So you do not really have a choice of unified look with server-side decorations; you have choice with cluttered mess between apps using different frameworks, or cluttered mess inside apps using different framework than the one used to render decorations.
So, how the other operating systems do it? They won't allow you to connect directly to compositor in the first place. You _must_ use the platform library, be it Cocoa or Win32 in order to be able to get a surface that gets displayed. And since you are already linking these libraries, they will paint the decorations for you -- unless you override it. All that is client-side, in the address space of your application, in your message queue.
Now, Windows does have a server-side fallback, when you app is not processing the message queue. Then it will paint the system decorations, but since your app is not responding, any synchronization is passe anyway.
So how to solve this in Linux? You will have as many looks, as many apps decide that they do not want to play ball, that they are a special snowflake, that need to avoid the "bloat" of frameworks. The cluttered mess of different UI styles and the permanently broken state of everything is a price you are paying for them to be able to do exactly that.
Otherwise, you would be able to reduce the looks to two (Qt and Gtk). When things would go very well, Qt could do what it does on other platforms and use Gtk+ look. That's about the only way to get unified look.
I'm not opposed to having mechanism to opt in to client side decoration, but making it mandatory is problematic for several reasons:
1. Different apps will draw decorations differently, leading to a lot inconsistency.
2. It means apps designed for other environments that don't draw their own decorations won't have any decorations.
3. If your client doesn't use one of the big all encomposing gui toolkits (not every app needs that), then it has to implement the decorations itself, which is non-trivial to do correctly (I know because I have worked on it for such an app).
4. You can't reliably configure the appearance and behavior of the decorations in a central place for all applications.
Fuethermore, if clients always draw their own decorations, then if you use a tiling wm and don't want decorations at all, you are stuck with them.
2) Only if they use server-side decorations only. In Wayland, client-side is mandatory and server-side optional. So if they do not have decorations, they are broken.
3) You client should use one of the big frameworks. On other operating systems, they are mandatory anyway. Only Linux allows your client connecting to compositor directly. Use that power responsibly. Frameworks bring lot of stuff implemented for you. If you reject that, it is up to you to implement that yourself.
4) You can't even with server-side decorations either.
Yes, with tiling, you get them. However, many apps have toolbar there, so you need it anyway.