Small ideas for themes; for the future, not the past

Hi, all. I was recommended to come here by blackcain.

I’ve been thinking about possible ways to improve upon the theming situation, and doing a lot of reading to try and get a feel for where things are going. I’ve read issue tracker discussions in the libadwaita repo and blog posts from various contributors to try and get a sense for things. I have this really huge stream of consciousness document about it, but I’ve tried to pare things down as best as I can.

The blog post that jumps out at me the most is this one by Jordan Petridis. And that’s the primary inspiration behind this small pitch.

In that post, Jordan made a theme. It’s a really, really slick-looking theme. But there is a key difference between that theme and what GTK3 has been doing for most of its lifecycle. That theme is applied on top of Adwaita’s stylesheet rather than entirely replacing it, and hence, having to reimplement it. As a result, the theme is comprised of very little code. And it works in synergy with the existing stylesheet and its conventions. In fact, it probably doesn’t even need to worry very much about how Adwaita changes.

So, how is the proof-of-concept theme even currently loaded? Well, that’s the part that stinks, and is what I would like to fix. Right now, you have to put it in xdg-config/gtk-4.0/gtk.css in order for it to apply on top of the Adwaita stylesheet. You can’t save it in xdg-data/themes/JordanSickTheme/gtk-4.0/gtk.css and load it that way for two reasons: currently, LibAdwaita ignores the gtk-theme-name setting and loads the Adwaita styleshet. It does however honor the GTK_THEME environment variable… but in so doing, replaces the stylesheet. So “JordanSickTheme” doesn’t have Adwaita underneath it as it is designed to, and thus everything would look really messed up but with a cool gradient.

In addition, this would all still affect GTK4 apps that are not Adwaita apps, and thus it wouldn’t really look right with them. If Elementary migrates to GTK4, it would mess up Elementary apps that are used alongside Adwaita apps. I think at the very least, some sort of care should be taken to make distinct the way that users customize GTK4-based platforms.

Adwaita seems like it’s trying to be distinct from GTK4 while still using it and affording GTK4 some sort of independence. So I think that in order to make things easier and cleaner for users who are determined to customize their system, but also potentially lay a foundation for a more desirable form of theming for everyone, Adwaita should look for platform stylesheets to load on top of its own, distinct from GTK4.

If this were to be enabled in the most minimal way possible without anything resembling real support, it could look for xdg-data/gtk-4.0/adwaita.css and load that after loading gtk.css. To go a teensy step further, it could check an ADWAITA_THEME environment variable for a theme: xdg-data/themes/$ADWAITA_THEME/adwaita-1.0/adwaita.css. And if you wanted to go further still, you could check the gtk-theme-name and load that. But in all of these cases, they load after Adwaita’s base stylesheet, not replacing that. No more wild west.

I think that this is an opportunity to make a concept for Adwaita theming as a concept that supercedes GTK theming, and would make GNOME a more appealing platform even for customizers and theme authors. I also think that it is a good opportunity to establish ground rules for what theme authors should and should not do, which is something we had in GTK2 but disappeared in GTK3.

Thanks for your time.

1 Like

Hi, you may want to check my comment here first to see if that would work for you: Home directory variable in gtk.css - #3 by jfrancis

The problem I think with loading an adwaita.css and such is that Adwaita is actually four themes: light, dark, hc-light, hc-dark. So such a scheme would likely have to take that into account. Maybe at some point media queries could be added that would work for these? Eventually though it seems something like that would be needed, because anything in gtk.css is also going to interfere with other apps that don’t use adwaita too.

Just to clarify that wasn’t a theme. It merely was a css snippet that applications load at runtime to accommodate the existing Stylesheet. Every application does that, as it should, and you have to in order to style your own widgets. For Example here we are loading a style.css file that we have compiled into a gresource.

    let provider = gtk::CssProvider::new();
    gtk::CssProvider::load_from_resource(&provider, "/org/gnome/Podcasts/gtk/style.css");
    gtk::StyleContext::add_provider_for_screen(
        &gdk::Screen::default().expect("Error initializing gtk css provider."),
        &provider,
        600,
    );

The blogpost was mostly from/and for the point of view of application and platform developers, I am surprised that people thought it was an actual theme tbh. Nothing has changed with regards to how the whole style sheet needs to be assembled. You are literary telling GTK to load a completely different stylesheet when using the env-var or in the past the gsetting.

While that is good, and something I make quite a bit of use of myself, I’m not entirely sure what it has to do with this. It wouldn’t create any sort of meaningful separation between customizations for Adwaita and GTK4 because conditional imports aren’t a thing. If someone were to try and use gtk-4.0/gtk.css as a means of loading a hypothetical Adwaita theme, they might have to make sure that the only GTK4 applications they are using are Adwaita applications unless all they’re doing is changing colors. Without some real means to customize the style of Adwaita and vanilla GTK4 separately, non-GNOME applications have less motivation to migrate away from GTK3.

That’s a great point! Really glad you brought that up. Didn’t a refactor recently land though that reduces the difference between all four of those versions to just color variables?

I don’t really understand how it isn’t a theme; you are displaying the GNOME Patterns app with an appearance that is different from the default. Is that not what a theme is?

Right, and that’s what I think themes should be, and hence why I’ve pitched this idea. I really think we should definitely move away from this thing of changing out the stylesheet completely.

I actually agree with upstream’s perspective that the way GTK3 themes work is completely busted because of the fact that they all completely switched out the underlying stylesheet. When you load up a totally blank theme, all you get is a completely transparent window with foreground text; that’s it. That differs from how it was in GTK2; a totally blank theme was just Raleigh. Widgets still had default spacing, padding, coloring, and basic appearance.

And in GTK2, themes weren’t allowed to do as much as CSS allows them to do today. There were rules that existed back then that just disappeared during GTK3’s development. Rules aren’t just means to restrict theme developers from doing whatever they want, but they were also means for theme developers and customizers to work in synergy with the baseline styling, and to “play nice” with the toolkit, in a way of speaking.

It would still technically be possible for themes implemented in this way to change absolutely everything, but I seriously don’t think theme makers would actually want to do that, because it would be a whole lot of work, and would be a cause of great consternation from app developers. Vendors definitely wouldn’t want to do that; I feel like all they would want to do is supply some color changes. I don’t think theme authors want themes to completely switch out the stylesheet, and I don’t think users want that either.

“All of this is only for application developers” is consistent with the project’s messaging, but there is also messaging from the project that says “we don’t want to stop users from customizing.” Without some meaningful way for users to safely add onto Adwaita’s CSS without affecting other GTK4 apps, users are still effectively stopped from customizing.

GTK2 themes literally worked by injecting code into unsuspecting applications. You may remember themes that were merely resource files, but the vast majority of people experienced GTK2 and GNOME2 themes as settings on different engines, like Clearlooks, Pixmaps, or Murrine. The only theme that made use of resource files without an engine was Raleigh, which was a Windows 95 lookalike.

The reason why stylesheets in GTK3 and GTK4 can do much more than the resource files colors in GTK2 is that we don’t allow side-loading theme engines any more; anything you could reasonably do with a theme engine is now the province of the CSS style machinery.

No that’s not a theme at all, that example was a modified version of the application and that css only applied to that application… It is not altering the appearance from the application from the outside in any way, its literary the same application but modified.

Right, the whole thing of loading arbitrary machine code was definitely bad, and it’s good that we don’t do that anymore. I’m part of that vast majority too; I used Murrine, Clearlooks, even Equinox to make and consume beautiful themes. But within the confines of those engines and the things you were allowed to change in gtkrc files, you could only do so much. But at the same time, it was also much easier to make themes and it was easier to do so with much less risk breaking absolutely everything. Sure, we could say “they were able to run arbitrary machine code, of course they were able to break absolutely everything,” but that’s not the reality of what it was like back then. (I do remember Andrea’s RGBA Murrine, BTW… that is an outlier because users had to patch GTK itself to install it, and they did so knowing it would break a lot of things.)

I’m trying to say all that to say that I agree with the general thread of belief that the fact that themes currently completely switch out all the CSS is bad. I am on that boat with you all. Sure, there’s no more arbitrary machine code, that’s great, but there’s also no enforced direction, no rules, no restrictions. People are left to reimplement convention rather than follow and adhere to it. If themes are CSS that is loaded on top of Adwaita rather than replacing it, then themes don’t have to do as much to create a desired look and feel, and the risk of breaking applications is dramatically reduced. Adwaita would end up being a sort of modern equivalent of a theme engine in terms of how theme authors would use it.

I feel like we’re muddled in semantics a bit, but I also feel like it’s important to be doing that right now because it’s clarifying the stance of the project.

As a customizer who is looking to preserve some sort of visual customization for users of GNOME and/or its applications, I saw that snippet of CSS and that screenshot of GNOME Patterns with it, and thought that it was a very nice and safe way to customize an Adwaita application’s appearance. I’m sure there are other customizers who thought the same, maybe even theme authors too.

But as a GNOME project member, where the primary concern at the moment seems to be attracting app developers, you wrote that from the perspective of wanting to show application developers what all they could do to customize their application’s appearance, and maybe you even wanted to emphasize the fact that users can’t do anything to change it.

I feel like the last few replies were about semantics rather than the merit of the idea itself, whether or not anything like that would be wanted by GNOME in part or in full, what sort of impacts it would have upon app developers or other stakeholders you are concerned about, etc. Sure, I get that we should clarify the semantics to make sure we’re really discussing the same thing, but I hope we’re now on the same page about these semantics.

So Jordan’s CSS snippet is not a theme, it is an application style. Okay, I accept that. But it could be a theme. My idea facilitates that in a much safer manner than the methods that are currently available, and will create much less headache for you all than if users start using GTK_THEME anyways, or putting overrides in gtk-4.0/gtk.css that risk breaking things in vanilla GTK4 instead.

That works if you want to use those colors, if you have custom colors then you’d have to use something else, i.e. the recoloring API.

Well not really. CSS is technically still just injecting executable code that could break the program. For example try putting this in your gtk.css:

* { transform: scale(1000); }

For me that causes all my applications to immediately crash. And even if they didn’t crash, it would still make them unusable…

That’s a bug and it should never happen. Please, file an issue with the version of GTK, a backtrace and/or a small reproducer.

In my opinion, this is not even worth reporting. The “bug” is with the CSS spec, not with GTK. Such things will also crash web browsers, here is another fun one that will slow everything to a crawl and maybe even the compositor:

* { filter: blur(1000px); }

The filter and transform properties are pretty powerful but also dangerous, that’s the trade-off for having them.

If someone else wants to report this then be my guest, but I think the worst of the issues (GPU starvation) would be covered by this and similar issues in mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/1975

Those CSS rules are very, very extreme examples. Those are not reasonable things that any user or theme author would or should attempt to do for any reason. I reproduced the crash on my system just by using the CSS panel of the inspector on gtk4-widget-factory, but like… of course it crashed. I tried to make every single part of the UI 1000x bigger.

I don’t know that an appeal to such extreme hypothetical situations is productive for the discussion at hand. I really don’t think that anyone in GNOME thinks that theme authors are out to break things on purpose by using CSS to do unreasonable things. I think that they believe that theme authors are doing their best, but breakages are happening regardless, because the ability to swap out the stylesheet is at odds with being able to use CSS to create reliable specifications and behaviors. Even when theme authors play as nice as they possibly can, it’s not really a sustainable model.

Even when you look at customizations for platforms that already use CSS, like for example Mozilla’s userChrome.css, or user styles that apply to specific websites, they don’t function by taking out the base stylesheet. They augment the base stylesheet.

Here’s the rub: it’s safe for apps to change the colors because they can QA. They can test that their app looks right with the colors they use, that everything has proper contrast, and that nothing looks broken. It’s not safe for users to do that because once again, changing colors arbitrarily can lead to breakage for apps.

My point here is that CSS is still a programming language. You can use it to break apps in weird and unintended ways just like you could with GTK2 themes, not much has really changed in that regard I don’t think. Neither seem to be suitable as a “safe” theming API. Sure you could say “I am not going to use transform and filter properties like that” but once you start to build up all these rules of what you can’t do then it’s not CSS anymore, it’s a very reduced form of it. At that point, why bother? You might as well replace it with something else.

I think the issues on the web are actually a reason to move further away from CSS. Augmenting the base stylesheet with userChrome.css also periodically breaks when the website owner changes the CSS, I personally have had websites break many many times because of that and I had to just give up on the userChrome. And even just trying to ship a large web app with multiple teams deploying CSS onto the same page is problematic, this is the whole reason why things such as Tailwind exist. The problem you are trying to solve (any number of teams deploying any number of CSS modifications onto any number of apps) seems to be the same thing but orders of magnitude more complex.

Those are both good replies.

I think I understand what you’re saying. The demonstration you gave is similar in effect to someone using machine code in a GTK2 theme engine to do something absolutely bananas that would just break everything, in contrast to how the vast majority of GTK2 themers would play by the rules and say “I want this type of gloss, and I want to use these colors here, and etc etc,” in effect only changing variables depending on contexts. At present, both usecases are accomplished by the exact same mechanism: CSS. Which means the separation between good behavior and bad behavior is completely nonexistent.

Thanks to you pointing that out, I think I agree with you; I’ve been convinced. My suggestion for CSS on top of Adwaita only solved half of the problem, that being that the base stylesheet could be removed. What you have pointed out is the other half: with CSS, we don’t have a meaningful way to prevent–or rather, protect–theme authors from breaking things they don’t mean to. I think that is something a true theming API would need to have. I already have ideas starting to bubble about that, but I wanted to at least provide an “okay, I got you” response before I think about that more and come back later.

I’m not sure how I feel about this response and I’ve been kind of crunching on that in my mind for the past day. So, the thing that I think is actually most important about theming is actually color scheme cohesion. The reason I pitched CSS augmentation is because it is the most straightforward and lowest-friction way to customize Adwaita’s colors, but I think color schemes matter much more than arbitrary CSS customization.

I’m using XFCE right now but I tried out KDE, and I configured KDE’s color scheme and icon theme to match what I had in XFCE. But I’m also looking to set up KDE Connect, and now that I’m back on XFCE, I start up the KDE Connect configuration app, and it has the same color scheme as the rest of my desktop. And it looks and feels good that way. Sure, the UI conventions and widget styling are different, but matching the basic UI colors makes it feel harmonious with the rest of the system.

When you look at customized setups, the thing that jumps out the most is the color scheme. Color schemes provide the strongest basis of a given theme’s identity, and there are enough prolific ones that people often use pre-existing ones to style their computer because they just look that good. Dracula. Nord. Gruvbox. Solarized. Even Adwaita’s grays are subtly different from Breeze’s grays and subtly different from Elementary’s grays.

You mentioned a tweet thread over on Reddit by Danielle Foré that changed my mind a little bit. That in combination with James Westman’s Platforms blog entry changed my mind a little bit too.

I think I am now on the page that we should strive to make Linux’s sub-platforms compatible with each other without making them amenable to being bludgeoned into complete homogeneity. However, I also think that the platforms should make an effort to fit into each others’ environments at least a little bit, and I think that the cleanest way to do this is with color scheme adaptability. I see Danielle’s point that the visual style differences are an indicator that you interact with an app differently, and I think that’s valid. But I also don’t think that is sufficient cause to simply give up on any effort for cohesion.

So thanks to Jason, I can accept that arbitrary stylistic customization is still too unsafe right now until we come up with a better idea. But as a result, I must double down on my belief that we at least have to have color scheme adaptability and configurability somehow. I don’t mean the FreeDesktop and Web definitions meaning light/dark, I mean KDE’s definition.

It seems like Adwaita was made in such a way that people making regular old desktop apps shouldn’t have to worry about what the colors are. They target a particular color name that is suitable for what they want to do, and it works. And that works for the GNOME project’s favor in case you want to redefine the colors; app developers don’t necessarily have to care about that. But it also means that color themes are extremely viable. If you have an application with a new enough libadwaita, you can customize its colors right now in gtk.css, but that would also impact an application that does want to define its own colors and style. I think it would be worthwhile to have some sort of layer between Adwaita’s base stylesheet and gtk.css that loads up new color definitions so that regular old desktop apps can seamlessly adapt, but applications that have some reason to stick out are not affected.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.