feat(Themes): add support for GTK3 dynamic theming

[euletheia]

'Proof of concept'

Instead of overriding named colors of all GTK3 themes via the config directory file, override only named colors for each variant of the adw-gtk3 theme (light and dark), and let GTK3 apps switch theme variant depending on the value of org.gnome.desktop.interface color-scheme.

This implies :

• that GTK3 apps will auto adjust their theme in real time, without having to restart them ;
• and that we can get rid of the stylesheet duplicata in the gtk-light-colors.css matugen template¹.

However, the main shortcoming of this method is having to rely on the adw-gtk3 theme being installed in the user themes directory² when package managers will install it system-wide in /usr/share.

This also entails that theming GTK3 apps without adw-gtk3 (via the .config override) would no longer be provided by DMS (at least I did not write anything to provide a fallback/choice).

Eventually, I don't know on which side you think the burden should weigh, but a stable solution could be to vendor the theme³.

Obviously, considering the size of the change, I could have overlooked some issues, but I've been using this patch for roughly a week and it seems stable.

Screenshots

contrib_DMS.mp4

Footnotes

1. At least my tests showed no blatant issue without those 8000 LOC. ↩

2. Considering they don't use the legacy $HOME/.themes folder. ↩

3. with a "dank" prefix to differentiate it from the original ? ↩

[real-or-random]

This implies :

• that GTK3 apps will auto adjust their theme in real time, without having to restart them ;

This will be great.

• and that we can get rid of the stylesheet duplicata in the gtk-light-colors.css matugen template1.

This would probably also solve #1555 as a side effect.

This also entails that theming GTK3 apps without adw-gtk3 (via the .config override) would no longer be provided by DMS (at least I did not write anything to provide a fallback/choice).

Sounds acceptable to me. The current way of simply overwriting everything with the adw3 light theme is certainly not better.

Eventually, I don't know on which side you think the burden should weigh, but a stable solution could be to vendor the theme

If DMS is committed to adw-gtk3 anyway, it can also ship it. And if a prefix is added, this really keeps it separate from the system installation.

[euletheia]

Following 8f10096 :

• reverted the majority of the changes to the Go and Qml code ;
• concentrated the logic in the gtk.sh script¹.

If iterating over the adw-gtk3 installation directory candidates in order of preference is enough, then I gladly embrace the minimalism of the solution, and there is - I think - no need for any discussion at all.

N.B. : this also reverts part of 8f10096 (since adw-gtk3 assets healing is no longer needed)

Footnotes

1. by recycling the check for adw-gtk3 installation directory introduced by the aforementioned commit. ↩

[euletheia]

So, I spoke too soon and way too early in the morning and things were not exactly correct to say the least.
Everything should be working now.

However, I realized that the main limitation of this "dynamic theming" is that if you change the theme colors (i.e., switch wallpaper) or matugen generation style while a gtk3 app is running, the theme won't be updated until you restart the app or switch between light and dark theme¹. It still is more dynamic than before I think.

Footnotes

1. A possible workaround would be to generate a dummy theme on the fly, so switching to it makes it look like the original theme was updated. ↩

[real-or-random]

@euletheia Is this ready for testing from your side?