On numerous occasions, we’ve talked about the issue facing non-GNOME GTK desktops, like Xfce, MATE, and Cinnamon: the popularity of Libadwaita. With more and more application developers opting for GNOME’s Libadwaita because of the desktop environment’s popularity, many popular GTK applications now look like GNOME applications instead of GTK applications, and they just don’t mesh well with traditional GTK desktops. Since Libadwaita is not themeable, applications that use it can’t really be made to feel at home on non-GNOME GTK desktops, unless said desktops adopt the entire GNOME design language, handing over control ovr their GUI design to outsiders in the process.
The developers of Libadwaita, as well as the people behind GNOME, have made it very clear they do not intend to make Libadwaita themeable, and they are well within their rights to make that decision. I think it’s a bad decision – themeing is a crucial accessibility feature – but it’s their project, their code, and their time, and I fully respect their decision, since it’s really not up to GNOME to worry about the other GTK desktops. So, what are the developers of Xfce, MATE, and Cinnamon supposed to do?
Well, how about taking matters into their own hands? Clement Lefebvre, the lead developer of Linux Mint and its Cinnamon desktop environment, has soft-forked Libadwaita to add theme support to the library. They’re calling it LibAdapta.
libAdapta is libAdwaita with theme support and a few extra.
It provides the same features and the same look as libAdwaita by default.
In desktop environments which provide theme selection, libAdapta apps follow the theme and use the proper window controls.
↫ LibAdapta’s GitHub page
The reason they consider libAdapta a “soft-fork” is that all it does is add theme support; they do not intended to deviate from Libadwaita in any other way, and will follow Libadwaita’s releases. It will use the current GTK3 theme, and will fallback to the default Libadwaita look and feel if the GTK3 theme in question doesn’t have a libadapta-1.0 directory. This seems like a transparent and smart way to handle it.
I doubt it will be long before libAdapta becomes a default part of a lot of user instructions online, GTK theme developers will probably add support for it pretty quickly, and perhaps even of a lot of non-GNOME GTK desktop environments will add it by default. It will make it a lot easier for, say, the developers of MATE to make use of the latest Libadwaita applications, without having to either accept a disjointed, inconsistent user experience, or adopt the GNOME design language hook, line, and sinker and lose all control over the user experience they wish to offer to their users.
I’m glad this exists now, and hope it will prove to be popular. I appreciate the pragmatic approach taken here – a relatively simple fork that doesn’t burden upstream, without long feature request threads where everybody is shouting at each other that needlessly spill over onto Fedi. This is how open source is supposed to work.
I really appreciate Mint’s eagerness to stand up for what users want. I don’t think Libadwaita are going to be happy about it, but they created a real problem for others. There’s too much “my way or the highway” posturing, we need to find better ways to work together 🙂
You are right of course, but it is not easy: for us, the Gnome desktop is like a common good and we feel like it should consider everybody and each aspect of life. We feel like the developers should feel responsible for our needs just because we do love the product so much.
On the other hand, the individual developer just wants to shape some of his own ideas, for himself, mostly unpaid in his scarce spare time. He does not see or feel the silent love and appreciation for his work because he will receive mostly hot criticism and flames from a small minority of very loud users.
All our successful OS projects started as small experiments born out of personal interest. They are still ran like that even years later when they became large and important. And at this point it becomes more and more difficult to balance between the developer’s own interest and the large social responsibility they imply on him.
TL;DR. Just let me make it pink with green polka dots.
I still cannot fathom the need to push mobile ui paradigms, which aren’t even that intuitive on mobile, into the desktop. What’s wrong with having a bit of text as opposed to all the obscure iconography?
Needless to say, I welcome the Minty team’s efforts.
Agreed. I use a desktop machine for the superior interface vs a phone. But people are dumbing down desktop interfaces all the time so that they look more like mobile uis.
This writing is so much more balanced and pleasant to read than those tiring AI rants.
Some pros, some cons, some subtle opinion. I love it, Thom.
Definitely shows why Thom is good at what he does when needed. The AI, xorg and Apple rants get tiring.
As an XFCE enjoyer, this is a welcome initiative. I hope it catches on.
It is not just the GTK desktops that can benefit. This should make GNOME apps look much better in KDE as well.
How are we affected? I am on XFCE too, though I do use mostly the original Gnome programs (e.g. Nautilus instead Thunar). I use heavy theming (TokyoAtNight) and “libadwaita-without-adwaita” and everything just works?
I welcome this initiative also though my understanding was that only pure Gnome Desktop was affected?
It’s particularly bothersome when using more traditional, csd-less theming.
Most recent annoyance I can recall was when trying out the latest Pinta, which doesn’t even have the option for enabling a menu bar.
Makes it stick out like a sore thumb in the theme that I am using.
It will only “just work” for apps that use the new library. So basically, Thunar in the future probably, Nautlius not a chance in hell, unless you or someone else forks it to add libadapta instead of adwaita as a dependency.
I think the oppoosite. Gnome Desktop will be unaffected. The idea is that Gnome apps will better respect the theme when run on non-Gnome desktops.
libadwaita-without-adwaita works similarly but only for GTK4 themes I believe. The idea here is to make libadwaita apps (Gnome apps) feel more at home on GTK3 desktops.
Back in the days I was using Linux as my daily desktop OS, I was really an avid fan of Mandriva, which starting in 2006-2008 I guess, shipped both its gnome and kde desktops with a common set of themes that were nearly identical so you could use a kde app within gnome that would look almost the same. That was neat. They used the whole freedesktop.org ecosystem to deliver cross-desktop interopability and it was neat.
Look at this video, you can see the user using a kde dekstop on mandriva and running gimp. Same aspect.
https://youtu.be/j2KUJskhJbw?si=p2BzKDUNQyiCG9F2&t=244
Mandriva was really a cool desktop, seriously.
I wish they’d just Fork GTK3 and call it something else and move on. I hate GNOME, MATE is my desktop of choice, I’m running it on Wayland and it’s working great on my laptop and desktop. Had to tweak a few things to make it the same as the X11 experience. I’d rather they just put a bullet in GTK3/4/5 uncertainty and create CTK or MTK or some other thing and move Cinnamon and MATE to it. I’ll port all my apps over and never look back at GTK.
Wait…you can run Mate desktop on Wayland now? I know that they’ve been working to make it possible, I was not aware it had reached a point where it could be a daily driver. I’m on Ubuntu-Mate can you give me a link to how you’re doing this? Thanks!
Yes, basically there are caveats to MATE on Wayland. I am running debian 13 (Trixie) and my MATE packages are custom. I do not modify the MATE sourcecode. Marco is replaced with Wayfire. There are two scripts called mate-wayland.sh and mate-wayland-components.sh which handle the session management. Overall it works quite well, but there are some rough edges which the MATE team are working to get rid of. A lot of control panel items in mate-control-center break on Wayland, but I use WCM (Wayfire Config Manager) with a patch I developed/got accepted upstream to launch individual plugins in WCM to replace the broken control panel bits. Things like Mouse/Keyboard/Appearance settings. We need more devs to help get MATE ready for 1.30 which should fully support Wayland.
That is what the XApps initiative was all about. Mint already tried forking popular GTK apps to keep them on GTK3.
https://linuxmint-developer-guide.readthedocs.io/en/latest/xapps.html
The reality is that they do not have to resources to maintain all these apps and they are falling behind. At the same time, more and more GTK apps are adopting libabwaita. Mint cannot fork them all. This new initiative takes the different approach of letting app devs move to GTK4 and beyond while trying to make those apps fit in on traditional GTK desktops.
The problem with using something called GTK3 is that developers will always look and go GTK4 or GTK5 is better because of the version number attached to it. It’s just an unfortunate fact of human psychology. By breaking with the naming convention they are much more likely to attract developers. I would just call it Desktop Tool Kit (DTK), drop the version number and focus on getting Cinnamon/MATE/XFCE and a few core applications: e.g Text Editor, Music Player etc. There’s too much duplication between MATE and Cinammon/XFCE at the moment. They should be combining efforts especially MATE/Cinnamon. Hamburger menus are awful on a desktop system. I’m running dual 30″ 2560×1600 monitors. I can afford the space for file/edit/help menus. GTK4 is already so GNOME centric it’s breaking apps/environments. I ported some code to GTK4 to see what it would be like and the results were awful, but it’s a lot of effort to maintain two builds. I’d rather just drop GTK and move once to a permanent fix.
Exactly this. Mint is biting off more than it can chew after just dropping basically the same project.
Fork you, Gnome 😛
I’m certainly biased, because I actually like GNOME 4 and understand their will to offer consistency. They already offer many accessibility options and I’m wondering which use case would make theme support a sensible addition.
The fact that so many people work on GNOME derivatives or forks instead of embracing KDE which would certainly caters their need for customization still confuse me.
I can’t think of any “big” application that is only based on GNOME’s technologies, including libadwaita. They usually stick to plain GTK3 or Qt.
+1 for people not using Qt instead of Gtk. Nowdays I feel the license war that lead to the creation of an alternative toolkit, gtk, is way over in the past.
But I do respect preferences, so maybe it is time we work on a standard for theming that all toolkids like Qt, gtk, wxWidgets and others could use. While I do understand there are diferences between those ui-wise, I think we can overcome that, if we want it hard.