Themeing and GTK4

[Secret-chest]

Hello. What are the plans, now that GTK4 and libadwaita are used more often, for themeing in Linux Mint?

Will you ditch full themeing or parts of it? Is there anything on the cutting board? I hope not.

GTK4 does support themes, but libadwaita doesn't - it may be possible with some clever hacks.

Though, GTK4 doesn't support menus anymore. Are we going to do an extension?

[mtwebster]

https://blog.linuxmint.com/?p=4586

Don't know yet.

[Qronikarz]

What are the plans, now that GTK4 and libadwaita are used more often, for themeing in Linux Mint?

Mint 22 is going to be an important release where the developers have to make some pretty big choices (not only theming related).
I don't think they will ditch the GTK like Solus and Pop_OS (interesting read here: https://joshuastrobl.com/2021/09/14/building-an-alternative-ecosystem/), but more programs may end up as Mint forks.

Libadwaita could be themed with Gradience program, but it's generally advised against making distro wide theming for that - https://stopthemingmy.app/

[anaximeno]

It's a bit complicated to force theming if developers don't want it (according to https://stopthemingmy.app/), also creating forks will just increase the number of apps that have to be maintained by the team, which could diffuse the attention devs give to the different repositories here, so this is a difficult decision to take (I suppose).

[Secret-chest]

The problem isn't just about themes. People now think there's a single Linux and that it's GNOME, so they design the apps around it.

[billyswong]

@anaximeno Those anti-theming advocates ignore that themes aren't just about aesthetics. They currently also serve for accessibility. In current GTK, users can only tune the default font family and font size independently. Users can't tune UI density with a simple knob. Selecting among light / dark / high contrast modes is not enough. Selecting accent colour is not enough. The only way to specify the UI density / padding / margin in GTK currently only works with full theme.

If anyone claim their application UI is so rigid that they can't handle dynamic density adjustment, their UI will also fail in handling internationalization as well. Written languages vary in their line height and visual length for the same visual clarity. A well-designed application frontend must be able to adapt to dynamic height and width of each non-scrolling text regions.

And about all the colour breaking in custom widgets, it is the problem of current CSS doesn't let an element "inherit" CSS properties outside its immediate parent. So the custom widget designer may be difficult to express "I want this text coloured like other text in normal themed text input boxes" in a clean manner.

They can create infinite excuses of why the current CSS architecture for general webpages can't do that, but it is still not an excuse of why an amended CSS architecture for native UI theming can't.

[Secret-chest]

I fully agree. GTK CSS should have had an @inherit <selector>; rule so you can make it use the style of something standard and only make minimal channges.

[knghtbrd]

@anaximeno Those anti-theming advocates ignore that themes aren't just about aesthetics. They currently also serve for accessibility. In current GTK, users can only tune the default font family and font size independently. Users can't tune UI density with a simple knob. Selecting among light / dark / high contrast modes is not enough. Selecting accent colour is not enough. The only way to specify the UI density / padding / margin in GTK currently only works with full theme.

To be fair, the ones responsible for the decision have an established tradition of not giving a crap about accessibility, telling the disabled they're using their computer wrong, and then mocking them and their disability. So … I don't expect your argument to be persuasive.

From my perspective, GTK4 is entirely a non-starter. I've heard it expressed more than once (not by Gnome folks—I don't interact with them anymore, and I've already given my reasons) that the G in GTK stands for Gnome, it's their widget set, and libadwaita/libhandy are the correct way to do things if you're going to use it.

This is unfortunate since GTK3 is not perfect, and will go the way of GTK2 in time unless it's forked. If it is forked, it needs active development, not just maintenance, and that's kind of a tall order.

None of which actually deals with the issue at hand that GTK4 apps simply do their own thing, and there's not a whole lot of control over that. I found this discussion because gnome-online-accounts-gtk does not (at least on an Arch system) respect your color scheme even. Dunno why not, was hoping to find the solution.

[JosephMcc]

Just to clear something up. Gtk4 isn't an issue. It themes the same way Gtk always has and Mint's themes support it. The issue is only with apps built using libadwaita. That unfortunately accounts for many apps under the GNOME umbrella.

[Secret-chest]

I mentioned that in the OP. However Gtk4 lost the GtkMenu* stuff.

[axel358]

@Secret-chest u can build classic menubars with gtk4 u just have to use GMenuModel. Imo the best thing we can do for libadwaita apps is to support the xdg portal implementation for accent colors but stay away from them for core apps. At some point every existing gnome app (even non core apps) will migrate to libadwaita, Terminal and System Monitor just recently started their ports. This has been discussed already but keeping apps frozen in time just before they made the libadwaita transition isn't a good solution either, for example the differences between mint celluloid n upstream celluloid are getting more noticeable as the latter gets bug fixes and new features

[Secret-chest]

@Secret-chest u can build classic menubars with gtk4 u just have to use GMenuModel. Imo the best thing we can do for libadwaita apps is to support the xdg portal implementation for accent colors but stay away from them for core apps. At some point every existing gnome app (even non core apps) will migrate to libadwaita, Terminal and System Monitor just recently started their ports. This has been discussed already but keeping apps frozen in time just before they made the libadwaita transition isn't a good solution either, for example the differences between mint celluloid n upstream celluloid are getting more noticeable as the latter gets bug fixes and new features

We can fork the terminal and system monitor.

[axel358]

Kay so playing around with libadwaita-without-adwaita (read the pinned comment) gives mixed results but not as broken as expected.

The broken looks seem to be mostly caused by the lack of support of Mint-Y for the new libadwaita widgets/style classes.
Im not suggesting any themeing attempt by default beyond accent colors but adding support for these widgets in case users want to force Mint-Y on these apps

[Jopp-gh]

Mint offers too much theming in my opinion. I suggest to introduce a file format to change appearance for both system and apps. Css would be a great format for theming, eg theme.css

I just hope to get consistent, not white windows in my dark theme in future too.

Most important theming elements are:

• main background
• Secondary windows
• toolbar
• all kind of buttons
• panels

[Secret-chest]

Themes already use CSS

[Jopp-gh]

Thanks, I'm a new Mint user.
Is css applied to apps as well? How to access the rules to style Mint and apps?

[anaximeno]

You can find local themes at $HOME/.themes and global themes at /usr/share/themes and yes it is applied to apps. Go to the themes module, in advanced settings, move to the add/remove section and from there you can install third-party themes.

[mfreeman72]

This is perhaps already known, but this is new to me. I just discovered that if a theme has GTK-4 support, you can add a .pam_environment file with the following line: GTK_THEME=name-of-gtk-theme, then log out/in or reboot, and libadwaita apps seem to adopt the gtk theme fairly well. At least it looks closer to the system theme than libadwaita's default theme does. Could a function be added to System Settings > Themes to automatically add this line to .pam_environment, and perhaps somehow automatically restart the wm so you don't have to log out/in or reboot?

[JosephMcc]

Just to clear one thing up. Gtk4 support is not enough. Themes need specific support for libadwaita widgets for this to work properly. The problem is many themes do not since it requires hacks like this for it to work.

[mfreeman72]

Ok. That makes sense. This whole thing is just incredibly frustrating for users. I'm sure it's not a walk in the park for the Mint devs, either.

[Jopp-gh]

The other day I studied the CSS stylesheets of Mint-Y which made me think, wow, how should theming work, if you can't modify the rules without visual feedback in real time!

Also, I tried to copy theme resources into ~/.icons to modify some resources of Mint-Y but this didn't seem to work for me. Probably I miss some details.

Currently I maintain a CSS stylesheet for Obsidian, which is fun and easy in comparison. Obsidian gives you a developer console and tools to interact dynamically and nicely with all elements of the graphical user interface, with immediate visual feedback when you modify CSS rules. Such tools are useful and the way theming should work, otherwise it's no work but just pain, imo.

Mint would need an exhaustive wiki to give interested parties the tools to theme Mint from start and finish to mitigate the friction of this complex building process - in absence of a interactive console or a theme editor.

Alternatively, also a bash script could be a generic theme editor, at least to build the basics. Mint's main landing page should give indications how to build a theme from scratch, at least giving the right paths and specifications for folks able to deal with code. I checked the documentation on https://www.linuxmint.com/documentation.php but didn't find anything about theming. Maybe I didn't check too thoroughly.

Theming Mint wouldn't be so interesting for me, if all themes would support the same amount of features.

Example, Mint-Y is OK but doesn't come with the same variety of emblems like ePapirus, also mime-types in Mint-Y are very generic for the most part, at least for the files I use. That's a pity.

On the other hand, ePapirus doesn't support the Nemo plugin **folder color switches which is so useful to highlight the status of folders.

ePapirus
This icon theme has all kind of colored directories svg's, so Nemo's folder color switcher would need an update to work with this very nice, icon theme as well.
Also, with ePapirus selected, some Apps don't apply the dark theme. The App icons then, are nice but superfluous and no more up to date.