Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gnome to prevent theming, wider community not happy

osnews.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Gnome to prevent theming, wider community not happy

#31

Post by Abishek_Muthian »

cheesetable wrote: post #8

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.

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.

Re: Gnome to prevent theming, wider community not happy

#32

Post by nix23 »

ncmncm wrote: post #22
MR4D wrote: post #7

Ok, everyone, time to go back to Enlightenment and try this again. https://www.enlightenment.org/ss/?page=2

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/

Re: Gnome to prevent theming, wider community not happy

#34

Post by lavabiopsy »

TingPing wrote: post #12
tadfisher wrote: post #11

Earlier quoted context omitted.

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.

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.

Re: Gnome to prevent theming, wider community not happy

#35

Post by lavabiopsy »

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...

Re: Gnome to prevent theming, wider community not happy

#36

Post by lavabiopsy »

type0 wrote: post #24
esarbe wrote: post #17

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 "Firs…

> Which has been implemented and delivered. 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.

Re: Gnome to prevent theming, wider community not happy

#37

Post by lavabiopsy »

esarbe wrote: post #18
rektide wrote: post #2

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…

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.

Post reply on HN