Libadwaita 1.0 has been released, just at the end of the year.
Libadwaita is a GTK 4 library implementing the GNOME HIG, complementing GTK. For GTK 3 this role has increasingly been played by Libhandy, and so Libadwaita is a direct Libhandy successor.
Libadwaita is quite controversial, as aside from dark mode and a (promised) colour API, applications that use Libadwaita cannot be themed. It’s all the result of developers being unhappy us pesky users get to decide what our computers look like, so they decided to prevent users from theming their systems at all. GNOME’s own applications will surely transition to it, and it remains to be seen if the wider Gtk developer community will opt for it as well.
Libadwaita hjas already led to two major departures from GNOME, and other Gtk-based desktop environments, such as Cinnamon and Mate, may follow.
libadwaita is like systemd: a nasty, oozy, dark hole that no one deserves to be punished with.
But why, Oh why, isn’t Desktop Linux the success it deserves ?
I’m wondering…
Those who put the money and efforts, get to play, others just complain.
But, I like it? Gnome is going to Gnome. They always have. This isn’t surprising in the least. But I use Gnome because its the best, most complete and functional Desktop. This is a signal, imho, that they are committed to doing that over offering choice. I respect and admire that. Just give me something that works, regardless of the color scheme.
Talking of “freedom” in Open Source.
In some instances closed source software looks like an angel in comparison.
And don’t get me started on how utterly restrictive GPL is.
You know you’re not forced to use the GPL, right?
Good luck trying to run Linux without using GPL.
You know you’re not forced to use Linux, right?
Using Linux and developing for Linux are two different things, you know. You only have to agree to the GPL if you’re working with GPL code.
Artem S. Tashkinov,
It’s one thing to have an anti-GPL opinion, but there seems to be either a misunderstanding or deliberate misrepresentation here. The GPL does not place any restrictions on end users. It only places license restrictions on derivative works and then only when those derivative works are publically redistributed. Claiming it’s restrictive compared to close sourced software is illogical given that closed source software doesn’t generally allow redistribution at all – the only activity that is restricted by the GPL.
Can a business buy one copy of windows and office and install them on hundreds of desktops and servers? Can they resell it to others? Can they change it without permission? No they can’t. The restrictions are already omnipresent before we even get to source code.
You may feel the GPL is too restrictive compared to LGPL, BSD, etc and you know what some people may agree with that. But closed source software as we know it is definitely more restrictive than the GPL when it’s given a fair comparison.
In closed source software you usually wouldn’t be able to do much about it. Without some potential reverse engineering and hacks involved. In open source software you can for example develop a drop in replacement library and regain control over theming GTK apps. Hence i don’t exactly understand on how you came up with the conclusion that closed source software is much more liberal and forgiving in this regard.
@Artem, GPL is a cascading freedom, users of GPLed software must be forced to license their software in GPL if their software is a derivative work. You still have freedom, because you can even sell the GPLed software anytime you like without restrictions.
In closed source, you can’t sell it because you are not the owner. In GPL, everybody is the owner, so it is up to you how you add value to GPL software you are selling.
Even if you just add an installer (ie. Sourceforge) ?
Kochise,
That’s a good question, My gut feeling is that this is not a derivative work because the bundling is acting more as a container than a derivation. However a very literal reading of the GNU’s description here may put that into question:
https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation
Still, because the installer obviously isn’t otherwise using the GPL program itself, I don’t think it should count as a derivation even if it’s in the same executable file.
I am not the biggest fan of the GPL. That said, it is pretty hard to argue that the GPL is more restrictive than proprietary licenses. As a user of the software, the GPL provides mostly freedoms as it purports to do. One area that the GPL is clearly better than proprietary options is in longevity in that I can continue to use the software as long as I like ( barring blatant violation of the license ). The GPL makes it very likely that you are getting to use software for little or no money as well.
As a “developer” of the software, as a distributor of the software, or even just somebody that wants to modify it for my own use, the GPL creates all kinds of restrictions and takes all kinds of freedoms away. Again though, that is relative to other Open Source options and not so much to proprietary commercial licenses which generally do not give you the right to modify or extend, or even to continue to use the software at all.
If Gnome were fully proprietary, a move like this would leave users with no recourse at all. With the GPL, we could always write our own compatible replacement for libadwaita that brings back or adds whatever capabilities we like.
I am not supporting Gnome’s move here by the way. I consider it fairly user hostile. Then again, the “why hasn’t desktop Linux succeeded” comment from above might also be answered with a comment about the lack of consistency and universality in the Linux desktop which is exactly what the Gnome guys say they are addressing. In my view though they will be unlikely to get the benefits they are looking for. The System76 response seems to indicate that they will get more fragmentation than unification out of this move. Most Gnome decisions have done this really. I am typing this on a system that uses Cinnamon which only exists in response to an earlier Gnome move. I like Cinnamon and so I am quite happy that Gnome rocked the boat enough to cause it. Budgie is already a “non-Gnome” piece of the Gnome ecosystem in very much the same way. This diversity is both the strength and the weakness of the Linux Desktop so I am not arguing for one or the other. My main comment is that Gnome is once again trying to dictate to their users what is best for them and that, as before, I would expect the result to be that “pure Gnome” will lose even more market share. If you are Apple, you can choose to have a small but profitable market share using the Gnome strategy. It seems a more confusing strategy for an Open Source project. But everybody scratches their own itch as they say. I am not a Gnome contributor and so my opinion does not really count for much.
Time to move away farther from GNOME and its crap, I hope that some other toolkits apart from Qt get the attention and respect they deserve.
I agree. IF not for Ubuntu, I will never use GNOME based desktops. Good thing Ubuntu customized the default Gnome which in my opinion is very ugly. It started with GNOME 3.
The GNOME project was already hinting in the early parts of the previous decade that they wanted people to look at a screen and instantly know it is GNOME. This is just solidifying that desire.
Doesn’t matter for me anymore. I was fed up with grafting on the features I want in a desktop with extensions with all the subtle little glitches as a bonus. I switched to KDE recently. They increased in quality leaps and bound since I last used it years ago. Does exactly what I need from a DE.
These people are not professional developers. It’s really that simple. Random ideas implemented because of dogma of the week really don’t cut it and closed versus open source doesn’t come into this. Arbitrary decisions, unnecessary duplication, and unfinished or none functional projects are a waste of time, effort, and energy. This is why standards matter and why feudal kingdoms imposing their own unaccountable decisions through the back door tend to get prosecuted or sued in any other domain.
Myself I would rather all the parameters and functions and defaults for a desktop environment apart from the most minor of tweaking be good out of the box. That requires expertise from the top level project management all the way through the multiple factors and coding standards. It’s the job of the designers to get it right so I don’t have to. Once some old fart or wet behind the ears random yahoo with too much testosterone between their ears begins to trip this up and make my life more stressful and inconvenient than need be they know where the door is.
Holding your users to hostage is always a red flag. Always. It’s always best to dump the source of the problem and move on before the next abuse comes hurtling down the barrel. At some point the Gnome project is either going to be held to account or run out of victims. (Ditto Microsoft.)
Your misandry aside. You make some good points.
My personal opinion is that on the one hand, yes Gnome has messed up a lot over the years, with regards to poor defaults, non-customizability and needing sometimes-brittle extensions to fix things. But on the other hand, this particular news sounds like it’s satisfying your requirements that “all the parameters and functions and defaults for a desktop environment apart from the most minor of tweaking be good out of the box*. They are basically saying, just like on macOS, that the Human Interface Guidelines should strictly determine what widgets look like across the desktop and apps – an HIG which I assume has been created/vetted by experienced designers (probably in the employ of Red Hat). Other DEs, distros and power users may be up in arms because it’s preventing them from setting their user experiences apart from Gnome’s default, but that is not the same thing as saying that these defaults are actually bad for most users.
Also, I’m totally fine with Gnome and other parties going different paths. It was an uneasy truce to begin with that Cinnamon, Ubuntu and others used Gnome technology without embracing the classic Gnome UX. It worked for a while but it was more a by-product of Gnome 3 being a bit brain-dead than it was a well-thought-out collaboration. So now once more Gnome takes its “vision” on its own road, for better or worse, while those that want a themeable toolkit will need to go their own way based on GTK 3 or other alternatives.
Sure. As I said above though, the end result is perhaps more consistency withing “Gnome” but less consistency on the Linux Desktop. Whether this is a good or bad move depends a bit on how important those two relative goals are for you and how aligned you feel they should be.
Around a decade back ideas on how you can make one “shell” and use it across devices. Like the desktop PC, mobile devices, smartwatches … Such ideas got momentum. Nobody succeeded in that and it became obvious on why. Because lets say on desktop you want to be able to move application windows around and on smartwatches that just makes no real sense. Trying to mix this concepts together only lead to compromises on where a mix of compromises doesn’t work all that good on any device. And this is what happened to GNOME 3. After a decade of development they now have a “shell” that doesn’t satisfy basic needs for desktop computer usage and it just isn’t suitable for mobile devices. In addition what they did is they started to make more bad decision. They started removing useful features from GNOME claiming that is for the better on the long run. And people should just trust them on that. After a decade i feel it is safe to say they were wrong and the trust is now gone. If i read some GNOME focused news site most of the news content is about GNOME Shell extensions and not GNOME itself. People using GNOME don’t really use GNOME. They use GNOME plus a ton of extensions on top of it that makes their experience bearable. Such extensions people rely on to often stop working due to new version of GNOME being released. And there there is this mindset. If you say what i just said you will likely get attacked. Like for example most of the comments surrounding libadwaita 1.0 release. Some people now actually claim that this is what Linux on desktop has been waiting for all along. And now that you won’t be able to theme some GTK applications. Now Linux on desktop will for sure gain 10% market share. In my opinion this is just as bad as when some companies, like Microsoft, Apple …. decide to do do the same for the “benefit” of their users. It’s OK to fight that and perceive it as an anti-pattern. Don’t see on why GNOME should be an exception. As they are just as bad in this regard. What i did is i moved from GNOME to KDE. Hopefully more people will move away from GNOME and by doing that to reduce their overall influence on Linux. Linux on desktop deserves better than what their vision of it is.
For me, this would be a great improvement. While many power users like to customize their systems, it makes it a Nightmare when it comes to supporting them on a larger scale. X or Y doesn’t work, or Z interacts differently because the user has tied themselves in a knot of customisations they don’t know how to untangle when something goes wrong.
I helped reintroduce Linux as an OS choice into my organisation partially predicated on locking down the customisation choices available to the end users. In our case, a single distro, on an LTS cycle and a single DE.
It used to be an option to all developers at my organisation previously, but then was swept out because it proved incredibly costly to support the Linux desktops/laptops as each was effectively a setup in and of itself. For a hobby or personal machine that’s fine, as part of a fleet of 20 or 30 or 100 the cost simply isn’t worth it.
As you say you have experienced it yourself and see this as a great improvement. When trying to deploy Linux on desktop on a large scale in an organization. Can you provide some examples on what exactly did stop working when an individual user changed their desktop theme? I hear that occasionally and would be interested in some first hand experience from the people that had such issues in the past.
Most of the time it’s when instructions are sent and the user has moved their button locations around so their setup doesn’t match the screen shots in the instructions, which in turn made mistakes creeping in to be more common. And if support help was required, then each machine looked different and in some cases behaved differently (single vs double click).
The “worst” example was when a user had selected a theme that caused the buttons to overlap. So one button rendered on top of the other, effectively hiding the button they were after. This example sounds innocuous and niche, but it litterly took hours to work out, with reinstall of the app in question multiple times as well as plain googleing trial and error. Extrapolate that across a buisness and the support team began to resent any Linux support request coming in.
Adurbe,
Your points seem reasonable but they don’t seem linux specific. The problem might not be linux itself so much as users customizing their systems.
I do agree that standardization helps reduce IT costs but I will say that actually goes beyond linux. Some enterprises hold back windows and office versions as long as they can because microsoft themselves can be guilty of designing new user interfaces that feel alien with learning curves for no benefit whatsoever. This hurts productivity and costs companies real money.
IMHO company policy should take an employee’s role into account before prescribing the same OS for everyone since some employees like developers in particular might be more efficient on their preferred system.
I agree that these points I’ve given are more themeing specific than Linux specific. Plenty of Linux only quirks for a support team, but this thread is focusing on the pros/cons of GNOME removing the capability to theme the systems so tried to give those as examples. My current origination does try to offer options to the development team, but even this comes with costs, as certain code and deployments works differently between development OS so additional time needs to be spent making the code agnostic.
Adurbe,
I cannot speak for your organization obviously, but it also helps to have experienced linux admins in IT. I’ve seen companies give windows sysadmins double duty managing linux. Ironically they often are less qualified to handle linux issues than the linux developers they’re managing. I’ve been there myself as a windows sysadmin. Linux isn’t something you automatically pick up, it takes time to learn the ropes. Regardless though I think they’d become more proficient at supporting linux the more they gave it a chance.
Anyways I get the premise behind what you’re saying. Training adds cost and ultimately it’s the house that sets the rules.
Thanks for the reply. I do get your point and can understand that some people need to be guided step-by-step through some procedure to complete it successfully. And it makes sense for the picture in instructions to look the same as the interface. BUT said that i do feel that if a person is capable to change a desktop theme or to improve agronomy by changing the position of “close” button. That such person shouldn’t have much issues following the same instructions.
You’d Think so, but sadly people find a way!
This is the primary difference of individual users and users at scale. A single Dev on their system will doubtless manage. Expand it to 10 and one will get confused and not follow the instructions correctly. There is probably some named theory as an inverse of moneys and typewriters.
@Adurbe
I feel that nine out of ten is good enough. Nobody can do better. If we exclude “kiosk mode” alike devices then in my opinion the creative process used today is of such nature that it requires a high level of customization. An average IDE, graphic, video, CAD … application for professional usage today is highly complex and usually highly customizable. The claim it must be run on a non customizable desktop environment is hence moot. If you are unable to close an application window, due to different position of the close button, then you likely won’t use anything beyond “kiosk mode” professionally anyway.
If I would deploy Linux on an enterprise scale, I wouldn’t bother about extensions and other extra stuff. If GNOME is a usable desktop, enterprise users will use it. People in this area *do not* care about theming(they can’t demand theming!), as long the desktop and the application being used is functional.
What hinders Linux *desktop* is not because of GNOME or this distro wars, but the applications. I want to run Application X and if it runs under Linux, good, but if not, just use Windows!
Then again if you are a professional and do use your computer for work. And we are not talking about lets say POS terminals but some more creative process including more then one “tool”. In such case it is in my opinion crucial you are able to customize your (desktop) work environment in-depth. Without such ability the result is much less professional and more importantly it is lacking. Professionals hence likely don’t use stock GNOME all that often. As they need customization.
Oh c’mon Thom, let’s set the record straight. This comment isn’t even true today as a December 2021 working prototype shows and the API to support it more broadly is planned. Axe to grind?!
” … applications that use Libadwaita cannot be themed. … ”
https://blogs.gnome.org/chergert/2021/12/03/text-editor-happenings/
Recoloring
The most visual piece of work this week was in introducing recoloring support. It builds atop libadwaita and uses a CSS provider to override the colors in the theme. I expect there will be a recoloring API in the not-too distant future for libadwaita which will provide this for us.
When you select a style-scheme Text Editor will now use the colors defined in the scheme to alter how the entire application looks. For example, below are screenshots for a number of style-schemes both bundled with GtkSourceView and found on the internet.
This is mentioned in the original news. The fact is currently there is no such recoloring support in libadwaita. And if and once it will get introduced it is hard to say how useful it will actually be. That is once you will apply a theme and will be presented with the result on the screen. I have a feeling it will be lacking and things like installing a custom “theme engine” might be needed. To get satisfying results. Like it could already be done before the introduction of libadwaita.
I find System76’s departure odd. Am I the only one who remembers System76 upbeat blog post on Libadwaita, color API and Vendor Theming API?
https://blog.system76.com/post/187541504063/the-future-of-theming-on-gnome-and-more-from
It seems no work was done in 2020-2021 and they are mad. The problem for System76 is no one was willing to do their homework. System76 knows their theme better than anyone, so it seems reasonable that System76 do the bear minimum and documented Pop_OS theme. This is a necessary step before anyone, and I mean anyone, can start the process of creating a Vendor theme API discussed in the blog post. System76 clearly did not even do the bear minimum or share it with anyone.
Canonical also did not do their homework, but they are not crying to the internet about how mean Gnome is. Canonical is apparently now working on a Vendor API.
Now that being said, I am quite excited to see what System76 comes up with as their new desktop. I suspect it will still be based on Gnome in some form or another.
I do have a serious question. When was Budgie apart of the Gnome community? Budgie always seemed to be outsiders who used some of Gnomes libraries as a foundation, but were never apart of the community. What did the contribute or work on?
GNOME reminds me of Windows 98. The conversation along is similar to this:
Q: Why is it that Windows 98 needs so many tricks?
A: Because the thing was too buggy and need third party developers(GNOME Extensions) to fix things.
>Libadwaita hjas already led to two major departures from GNOME, and other Gtk-based desktop environments, such as Cinnamon and Mate, may follow.
Should have just used Qt-based KDE Plasma! It’s been around since the late 90s, it’s older than GNOME, has way more features and options, and certainly respects its users more.