Gnome to prevent theming, wider community not happy(osnews.com)
osnews.com
Gnome to prevent theming, wider community not happy
https://www.osnews.com/story/133955/gnome-to-prevent-theming-wider-community-not-happy/
36 comments
GTK has a stable theme api. This is happening in a different layer, which is more specific to GNOME apps.
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.
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.
This is weird semantics. GTK supports themes. The CSS classes are stable and will not change. Only libadwaita disables loading system themes.
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.
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've been using GNOME 40 for the past few months, and I'm impressed with the level of quality: intuitiveness, polish, features.
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.
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.
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.
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.
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. =)
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. =)
>Ubuntu to Arch to have a vanilla Gnome 40
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 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.
Ok, everyone, time to go back to Enlightenment and try this again.
https://www.enlightenment.org/ss/?page=2
https://www.enlightenment.org/ss/?page=2
Remember the time you could get a machine with this desktop/window manager at Walmart in the US? Good times.
You mean Tizen?
Tizen just uses the library's (EFL), he means something like that:
https://www.enlightenment.org/
https://www.bodhilinux.com/
https://www.elivecd.org/
https://www.enlightenment.org/
https://www.bodhilinux.com/
https://www.elivecd.org/
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.
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.
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).
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).
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.
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.
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
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...
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...
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.
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.
Talk about an unforced error.
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.
Linus would call that a Bug.
Does QT have some sort of issues with free software licenses? I wonder why QT hasn’t been used as widely as GTK. Maybe I’m mixing up GTK with Gnome?
Both Qt and GTK are LGPL
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.
It's a shame because as a user, Qt is the most pleasant of all the toolkits.
[deleted]
This might be relevant:
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
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
Might be relevant too related to elementary OS: https://old.reddit.com/r/elementaryos/comments/pm22kw/whats_...
> Which has been implemented and delivered.
what good is it when it was delivered in a broken state for many legacy GTK applications?
what good is it when it was delivered in a broken state for many legacy GTK applications?
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.
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.