Demystifying Theme Selection

[JoshStrobl]

This is a proposal for demystifying theme selection and providing a potentially simpler user experience for theme selection and introducing better cross-toolkit support.

Current Situation

At the moment our theme section breaks down to the following:

• A GTK widget theme selection with all items except those in our exclusion list like Adwaita / "Default"
• "Dark theme" toggle which only sometimes does something, depending on the theme or if we are using the built-in theme. This will currently set "gtk-application-prefer-dark-theme". Some themes respect this and others expect you to explicitly choose a different GTK Theme.
• Built-in theming, which is intended to be redesigned Redesigning the Internal Theme #22

Proposal

My proposal is to retain both our setting and respecting of gtk-theme, however present a UI that translates that option (alongside the dark theme preference). We would do this by us:

1. Maintaining a map of GTK widget themes to dark / light theming (we can also figure out if there is room to have theme developers ship a file that specifies which GTK theme to use in certain scenarios)
2. Leveraging that map to provide a simplified Widgets list. So instead of say "Materia-dark" you would just have "Materia".
3. Translating selections such as "Dark Theme" into "Materia-dark", a "Compact Mode" appearing where we know the theme provides one (so you could imagine it being "Materia-dark-compact" and "Materia-dark-compact" respectively). I'm open to ideas on how to handle scenarios like just Plata where it may be light with dark GTK Header, or if that is something we want to concern ourselves with entirely. This would still set the gtk-theme in the background, just the Widgets selection itself wouldn't directly.

Built-in theme would still be presented as a 3-option state:

• Dark: Always use dark theme regardless of GTK Theme
• Light: Always use light theme regardless of GTK Theme
• Disabled: Disable use of Built-in Theme, relies on any support from GTK theme, same situation as now.

Another key difference with the Dark theme toggle is I want us to introduce support for FreeDesktop Dark Style Preference. Toggling it on would set that option and at least ensure applications built with the likes of libadwaita would respect our dark theme user choice.

[serebit]

This would be a bit of an undertaking. We'd need to account for accent colors (provided by themes like Matcha), compact versions, hiDPI versions, dark and light and no-pref versions, and whatever other variations theme devs would come up with. The most rigid solution I can think of would be a configuration file provided by GTK themes that provides information about each variant and what properties it has, but adoption would be the main concern there along with potentially shoehorning theme developers into limiting their variants.

The simplest option here that I can see would be to list core themes in a dropdown, and then all variants for the selected core theme in a secondary dropdown. The most complex would be to account for every possible variation, have theme developers ship a config that itemizes each variant and its properties, and then show selectors for each of those properties.

I do agree that something needs to be done—the state of theme settings is a bit dismal right now. Support for the FreeDesktop Dark Style Preference would be excellent.

[JoshStrobl]

@serebit Yea, worst case is we start with the "base" or most popular items and fall back to having an "advanced" dropdown (maybe?) with all of the options.

The accent versions would certainly be tricky and while I believe I accounted for the compact version, I'm not sure of any examples where you have hiDPI specific versions (if you have any links, I'd love to see them).

provided by GTK themes that provides information about each variant and what properties it has, but adoption would be the main concern there along with potentially shoehorning theme developers into limiting their variants.

To be fair, there isn't a massive amount of themes that officially support Budgie, so proposing this may be viable for the themes that are actually being actively developed that also support Budgie in the first place. I do think we should stray from showing GTK Themes that we know don't support it (right now it's an exclusion list, but we could just as easily make this an "inclusion list").

[serebit]

In reply to @JoshStrobl

Matcha provides HDPI variants.

I think ultimately the way forward might be to see if we can reach out to theme developers and figure out if they'd be okay with including a file that Budgie can read with variant information. If a theme doesn't have this file, we fall back to autodetection (look for "dark" in variant name and extract that to a separate toggle) with all variants that we can't determine a category for being placed in a single dropdown.

For example, we could have Plata selected as the base theme, [Base, Lumine, Noir] as Variant, and [Base, Compact] as Sizing when autodetection is used. If a theme meta file were provided, we could have Variant extracted to a dark mode selector, and keep the Sizing selector.

[fossfreedom]

Copy paste this from Reddit. Before people start getting carried away from trying to hack around libadwaita issues by symlink their theme gtk4 folder they need to be aware of the following

"
Note that there is a big difference between using GTK_THME and simply symlinking .config/gtk-4.0/gtk.css to the gtk.css of a theme (like this does)

If you set GTK_THEME, the libadwaita style is not loaded, and the style of that theme is loaded instead.

But if you symlink ~/.config/gtk-4.0/gtk.css to a full theme, the libadwaita stylesheet will be loaded, and then the full theme in gtk.css IN ADDITION to that. gtk.css will override some css things properly, however what it doesn't override, will inherited from the libadwaita stylesheet. If the theme isn't designed to cope with this by resetting a bunch of things (you can't just reset everything as then you reset non-theme css providers too) then example the theme in gtk.css sets only a background color on buttons, and it is expected that there is no border radius, but if it doesn't set it, it will inherit the libadwaita border radius and it will be broken.
Although there shouldn't be too much breakage for themes that are based on the libadwaita stylesheet and only modify it slightly
"