android is just getting the ability to let users pick their colors & here's a bunch of appdeves irked that they cant override the user's ability to pick colors on linux.
i for one really really liked when i could make a nice theme, a look & feel for my computer. that was a cool time.
i dont know what the third way is. letting apps express power over the users sounds bad. wider fommunity here sounds like cantankerous bad actors.
edit: i'm way way way off here. apparently gnome won't let ANYONE theme. not users, not app-devs.
Yes, indeed. That's the idea behind libadwaita; if you are using it, you are buying into Gnome theming. If you don't want Gnome theming, don't use libadwaita. You can still use and theme Gtk all you want, but libadwaita will disable loading of themes.
>If you don't want Gnome theming, don't use libadwaita
This is not accurate, the current plan seems to be for libadwaita to gain a new theming API. Additionally, apps can still load CSS themes on top of libadwaita.
They're working on colour choices within Adwaita, which is basically what Android 12's Material You stuff is doing (that's just AI-powered and automagical).
What Android isn't adding is the ability to plug in a library that completely changes the way all the widgets render and which everyone writing applications has to step very carefully around because you never know what anything you write is ever going to look like (but you know users will moan about it).
Some of the free software community have long been suspicious of QT. Their recent decision to only provide closed LTS releases seems to justify that. Unless a community with more resources than KDE and less conflicting financial motivation than The QT Company takes it on. I'm sure there are also technical reasons. It's a c++ framework that doesn't bind as well to other languages as GTK.
Yes, although Qt is licensed under both the (L)GPL and a commercial license, The Qt Company does things such as making the current v5.15 LTS branch commercial-only when v6.0 was released. See https://www.theregister.com/2021/01/05/qt_lts_goes_commercia...
People always talk about the license and stuff but personally, i always shy away from Qt because the only real choice for language is C++ and maybe python. Gtk being written in C gives it much more flexibility in what languages can bind to it.
I think this is the biggest reason. Qt is half a GUI toolkit, half an elaborate library for making programming in C++ more bearable. It even has a custom preprocessor. Generating bindings for it is nearly impossible. C++ isn't the only game in town for desktop programming anymore.
It's a shame because as a user, Qt is the most pleasant of all the toolkits.
The writing's been on the wall for ages on this one...
GTK+ theming was never particularly stable and I get the impression the developers are tired of dealing with avoiding breakages or the fallout when they inevitably occur. It's easier to just outright drop support for it.
But it's unclear to me to what extent theming will actually be impossible. I presume the GTK+ look and feel will still be stylized more or less by a theme, it's just the GNOME theme which will always evolve in lockstep with the internal code. This way they don't have to care about breaking compatibility with third-party themes.
GTK has stylesheets, not an API. This is why libadwaita is the "GNOME apps" API, because GTK's themes are stylesheets and in no way form a proper API that preserves accessibility and usability for random GTK apps with custom controls.
The solution is an actual theming API, which is still in the discussion phase, and an interim recoloring API for distributions who mostly fork Adwaita but use branded theme colors.
If you mean GTK3/4 supports system themes, then no, that's false, it has never really supported doing that. The theme was meant to only be changed by the app, users changing the theme was always consider unsupported. Of course you could previously attempt to override it by setting an environment variable but this could cause any number of things to break because of missing or incorrect CSS classes. These distros were warned about this issue a long time ago.
Just to clarify: The reason for this is not because GTK's CSS classes themselves are not stable (you are correct that they are stable). The issue is that a theme's CSS classes cannot possibly be stable with respect to any given app's CSS classes, unless the app has explicitly enabled that theme, which is not possible with the current API. If you are using the environment variable then apps do not even have a reliable way to check which theme is loaded.
The feeling with GTK4/5 seems to be that GTK itself should only supply some basic default styles and should not bother handling theming at all. Instead that should be handled by another library which knows more than GTK about which CSS to load and when. This is what is essentially being done with the libadwaita theming API.
I have exactly the same experience. Actually switched from Ubuntu to Arch to have a vanilla Gnome 40.
Maybe we should just admit that this is the Gnome Way. If customization is super important for you, maybe KDE, .. are the better options. There's a choice. =)
I did exactly the same ~4mo ago, vanilla Gnome on Arch is blazing fast compared to the Ubuntu one...hell the whole system is, and the archinstaller is great! Perfect KISS i would say, if one need's more then do it the "old" way.
However Gnome40 was just installed to test it, since i use i3 normally, i cant stand the Windows shuffling anymore, it makes me just angry to sort the space on my screen, and i don't even use the tilling thing "correctly" just tabs, virtual desktops and sometimes a floating window.
Gnome is so little visible in my workflow I don't care what it looks like. It's the most out of my way and always there for me Desktop I've seen so far.
I had to switch to upstream GNOME on Arch to realize that my misconceptions about GNOME are largely from lackluster integration in the distros and bad theming from the apps.
I can stick out my neck to recommend upstream GNOME to any coming from macOS or perhaps even Windows. All default apps work great, often better than 3rd party alternatives. Where as in other DE's, I often had to replace default apps including even file manager!
So if preventing theming can preserve this usability, I'm all in for it.
In 2019 at Guadec there was a meeting between interested parties with regards to theming.[0] This was the meeting where the current direction of Gnome theming was decided on[1][2]. System76 was obviously (see[0]) a participating party at that meeting.
At that meeting it was decided that everyone at the meeting should contribute to the theming api. System76 at the time announced that they
"First, we’ll work together to identify and document colors that can be exported and modified by theme developers. These include header bars, buttons, switches and other widgets that theme developers often modify. This work also enables app developers to more easily customize the look and feel of their apps."
Elementary and the Gnome developers took over the Dark mode api. Which has been implemented and delivered. It would have been Budgie, Ubuntu and System76's job to get together, write a specification of what they need and then work on a proposal of how they want to achieve that. They didn't do that in the last two years and now they are complaining that Gnome didn't do the job they (Budgie, System76, Ubuntu) agreed to do.
I know, hating on Gnome is easy sometimes. But that really doesn't look like the Gnome devs are at fault. They communicated their intents and reasons years and years ago[3]. This should not been a surprise and complaining loudly about this now - to say the last - a bit dishonest with regards to their initial involvement.
There's still work with regards to a theming API by Purism's Alexander Mikhayelenko, but that work is ongoing[4].
That's generally the problem with theming, if some app does not support the theme (e.g. legacy apps that were not designed with theming in mind) then it will be in a broken state. Unfortunately not much can be done about it besides fixing the apps one by one.
What would happen to the high contrast option? Will it become obsolete too? My older relative is dependent on it, this would be a pain to migrate them to the new desktop environment.
In the post announcing libadwaita, it said that the Adwaita stylesheet "including its HighContrast and HighContrastInverse variants" was going to become part of the library. So don't worry, it's not going anywhere!
GNOME as a project does put a lot of effort into accessibility, they're not just going to throw those themes away. I think the key realisation here is that they consider them to be Adwaita variants, not entirely new themes.
Shame. Themes were probably one of the biggest reason I stuck with Gnome for so long, before eventually taking the leap to learn a tiling WM (Awesome rocks). Orchis theme was really pretty. I got the feel of a Google system, without the spooky monitoring.
I commented on this before, but GNOME is not preventing theming. The Solus developers have made their decisions based on missing and/or false information, and this article has unfortunately repeated that. See my longer comment here: https://news.ycombinator.com/item?id=28548467
36 comments
[ 0.24 ms ] story [ 92.5 ms ] threadi for one really really liked when i could make a nice theme, a look & feel for my computer. that was a cool time.
i dont know what the third way is. letting apps express power over the users sounds bad. wider fommunity here sounds like cantankerous bad actors.
edit: i'm way way way off here. apparently gnome won't let ANYONE theme. not users, not app-devs.
This is not accurate, the current plan seems to be for libadwaita to gain a new theming API. Additionally, apps can still load CSS themes on top of libadwaita.
What Android isn't adding is the ability to plug in a library that completely changes the way all the widgets render and which everyone writing applications has to step very carefully around because you never know what anything you write is ever going to look like (but you know users will moan about it).
It's a shame because as a user, Qt is the most pleasant of all the toolkits.
GTK+ theming was never particularly stable and I get the impression the developers are tired of dealing with avoiding breakages or the fallout when they inevitably occur. It's easier to just outright drop support for it.
But it's unclear to me to what extent theming will actually be impossible. I presume the GTK+ look and feel will still be stylized more or less by a theme, it's just the GNOME theme which will always evolve in lockstep with the internal code. This way they don't have to care about breaking compatibility with third-party themes.
TFA is too short on details.
The solution is an actual theming API, which is still in the discussion phase, and an interim recoloring API for distributions who mostly fork Adwaita but use branded theme colors.
Just to clarify: The reason for this is not because GTK's CSS classes themselves are not stable (you are correct that they are stable). The issue is that a theme's CSS classes cannot possibly be stable with respect to any given app's CSS classes, unless the app has explicitly enabled that theme, which is not possible with the current API. If you are using the environment variable then apps do not even have a reliable way to check which theme is loaded.
The feeling with GTK4/5 seems to be that GTK itself should only supply some basic default styles and should not bother handling theming at all. Instead that should be handled by another library which knows more than GTK about which CSS to load and when. This is what is essentially being done with the libadwaita theming API.
https://www.enlightenment.org/ss/?page=2
https://www.enlightenment.org/
https://www.bodhilinux.com/
https://www.elivecd.org/
This software works well on my Pinephone too.
I'm happy to trade my flexibility to allow the GNOME the flexibility to make improvements that benefit all.
I understand some want more flexibility, however.
Maybe we should just admit that this is the Gnome Way. If customization is super important for you, maybe KDE, .. are the better options. There's a choice. =)
I did exactly the same ~4mo ago, vanilla Gnome on Arch is blazing fast compared to the Ubuntu one...hell the whole system is, and the archinstaller is great! Perfect KISS i would say, if one need's more then do it the "old" way.
However Gnome40 was just installed to test it, since i use i3 normally, i cant stand the Windows shuffling anymore, it makes me just angry to sort the space on my screen, and i don't even use the tilling thing "correctly" just tabs, virtual desktops and sometimes a floating window.
I can stick out my neck to recommend upstream GNOME to any coming from macOS or perhaps even Windows. All default apps work great, often better than 3rd party alternatives. Where as in other DE's, I often had to replace default apps including even file manager!
So if preventing theming can preserve this usability, I'm all in for it.
In 2019 at Guadec there was a meeting between interested parties with regards to theming.[0] This was the meeting where the current direction of Gnome theming was decided on[1][2]. System76 was obviously (see[0]) a participating party at that meeting.
At that meeting it was decided that everyone at the meeting should contribute to the theming api. System76 at the time announced that they
"First, we’ll work together to identify and document colors that can be exported and modified by theme developers. These include header bars, buttons, switches and other widgets that theme developers often modify. This work also enables app developers to more easily customize the look and feel of their apps."
Elementary and the Gnome developers took over the Dark mode api. Which has been implemented and delivered. It would have been Budgie, Ubuntu and System76's job to get together, write a specification of what they need and then work on a proposal of how they want to achieve that. They didn't do that in the last two years and now they are complaining that Gnome didn't do the job they (Budgie, System76, Ubuntu) agreed to do.
I know, hating on Gnome is easy sometimes. But that really doesn't look like the Gnome devs are at fault. They communicated their intents and reasons years and years ago[3]. This should not been a surprise and complaining loudly about this now - to say the last - a bit dishonest with regards to their initial involvement.
There's still work with regards to a theming API by Purism's Alexander Mikhayelenko, but that work is ongoing[4].
[0] https://blog.system76.com/post/187541504063/the-future-of-th...
[1] https://discourse.gnome.org/t/gtk-adwaita-and-vendor-styles/...
[2] https://etherpad.gnome.org/p/VendorThemes2019/timeslider#161...
[3] https://stopthemingmy.app/
[4] https://gitlab.gnome.org/GNOME/libadwaita/-/issues/215
what good is it when it was delivered in a broken state for many legacy GTK applications?
GNOME as a project does put a lot of effort into accessibility, they're not just going to throw those themes away. I think the key realisation here is that they consider them to be Adwaita variants, not entirely new themes.
Also see this longer comment from a GNOME community manager that further explains it: https://old.reddit.com/r/gnome/comments/pokint/i_themed_http...