this post was submitted on 23 Jan 2026
10 points (100.0% liked)
technology
24182 readers
264 users here now
On the road to fully automated luxury gay space communism.
Spreading Linux propaganda since 2020
- Ways to run Microsoft/Adobe and more on Linux
- The Ultimate FOSS Guide For Android
- Great libre software on Windows
- Hey you, the lib still using Chrome. Read this post!
Rules:
- 1. Obviously abide by the sitewide code of conduct. Bigotry will be met with an immediate ban
- 2. This community is about technology. Offtopic is permitted as long as it is kept in the comment sections
- 3. Although this is not /c/libre, FOSS related posting is tolerated, and even welcome in the case of effort posts
- 4. We believe technology should be liberating. As such, avoid promoting proprietary and/or bourgeois technology
- 5. Explanatory posts to correct the potential mistakes a comrade made in a post of their own are allowed, as long as they remain respectful
- 6. No crypto (Bitcoin, NFT, etc.) speculation, unless it is purely informative and not too cringe
- 7. Absolutely no tech bro shit. If you have a good opinion of Silicon Valley billionaires please manifest yourself so we can ban you.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Here we go again (channeling the inner Matthias Clasen, one of the lead engineers in GTK)
Fix the apps that don't support Linux. There is a difference between porting to GNU/Linux and actual support. Hire formal engineers (not enthusiasts burning the midnight oil) to port to freedesktop and wayland or accept contributions/improve tooling.
Agree, apps and toolkits should implement their own libdecor. Libdecor was a stopgap measure for porting applications, but it's not an end all solution.
No, as the compositor cannot make decisions for the app's window bar and thus will choose the least common denominator approach (that being, libdecor). This is what KDE does, it's KDE's decision, but it cannot be everyone's decision.
This did not explain why this would be the case. An app's "look and feel" is much more than the titlebar. Padding, font, colors, widget design, animations, sound, etc all play into it. Even the way the settings menu is presented varies differently from app to app, from desktop to desktop.
GNOME applications use the adwaita platform toolkit which explicitly does not want the compositor to force window decorations on it as the window bar of these apps are a design feature. GNOME applications look like GNOME applications, this is intentional. As far as I know there isn't a toolkit that is so similar to adwaita that forcing a different titlebar wouldn't disrupt the application.
Customer is always right mindset is not the deciding factor in technical decisions.
App developers do not have a choice in adopting wayland. Legacy xserver will disappear in only a few years from distributions and xwayland is a stopgap measure. There is no fragmentation, CSD has always been part of wayland and will always be a part of it.
This is not part of wayland it is part of xdg-desktop-portals which is an abstraction separate from wayland (but used in wayland-based desktops to access desktop resources).
Ditto with top, this is part of the portal spec but also that some GNOME engineers in passing have mentioned that they don't actually want apps to make the file picker portal the de-jure implementation of file picker, if the app has its own way of doing file picker that's more suited to it than it should use that.
Deeply unserious.
If a fake protocol designed to ape proprietary systems that doesn't actually work both in theory and practice is the largest "issue" of GNOME then I would say GNOME has done pretty well.
Anyway article was written in 2022 so L bozo author GNOME will hold the line on Client-side'ist thought.