In gtk.css how could we define some styles on a per-application basis? Of course I have to be weird and pick gnome-calculator to start, and it doesn’t have any special window classes like some other apps do. But it’s window is called MathWindow with label name Calculator, and ID is org.gnome.Calculator is there a way to use those in a selector? I thought we could use labels? But if I try a selector with window#Calculator it doesn’t match.
This is not possible with gtk.css. It is also a bad idea because the cascading nature of CSS means the app could change styles in an update and then your styles would break. If you want to modify the app’s CSS then you should just modify the app itself.
Yes it’s possible! For example, for Nautilus, can use a selector starting with window.nautilus-window. I’m not distributing anything, so if things break later down the road I’ll just pick up the pieces. Trying to learn more about GTK and CSS in the meantime.
Those selectors are not reliable and I do not suggest using them. They are a bad workaround to make up for the fact that gtk.css is not meant for app style. It is not a matter of “if things break later”, they are guaranteed to break if the app changes any of its CSS semantics at all. The best case scenario would be if every app used CSS classes for its app id and version, but even that is still a bad workaround that won’t fix any of the other issues that make gtk.css bad for app styling. And most importantly, as you have found, the app can just not use those classes and then the whole thing doesn’t work anymore…
If you want to learn more about GTK and CSS just to debug and test things, I suggest using the GTK Inspector and entering your CSS there in the CSS tab.
Yeah I’ve been using the Inspector, thanks, that’s how I found out so much already. Well when things break, it won’t much at least, just have a few lines to make the headerbars smaller. Would be cool if there was a way to apply specific styles to the calculator though.
It’s a bit confusing because I think CSS uses certain terms to refer to certain things but GTK may use different terms to refer to the same things…
CSS #id Selector here it says to use # with the ID which is org.gnome.Calculator right? But #org.gnome.Calculator nor window#org.gnome.Calculator nor *#org.gnome.Calculator match anything.
Gtk – 3.0: CSS Overview here it says to use # with names? so that would be my original thought with window#Calculator, and also tried #Calculator and *#Calculator and they didn’t match anything either.
The id is just a string that the developer can set to whatever they want for any widget, using gtk_widget_set_name. The developer does not have to set this and even if they do set it, there is no guarantee that it actually does what you want, because the app can load any number of other styles that conflict with yours. And yes, this is very confusing that it isn’t gtk_widget_set_id. It makes much more sense in HTML because there it’s actually set with things like <p id="my-element-id">...</p>.
I think in general there is a lot of confusion in the community, from people who did not come from a web background and do not know what CSS is for. It is a declarative language for developers to style their own content. It is not meant to allow you to inject random themes onto random things and expect that it will work. If you want to apply specific styles to the calculator, you should just modify the calculator app itself. That is the only reliable way to do it.
Yeah but how am I supposed to do that? Download the source code locally and compile my own version? Then I have to make a new launcher for it and remove the system’s launcher. Then what happens when the code is updated? i have to download and re-compile the new version? It presents a whole other set of problems…
If you and your system are not set up for GNOME development then I would not suggest modifying the styles at all, it’s not worth it. If you want to style the app then you must do all that anyway, to be able to respond to any changes in the CSS that would break your styles.
Just for some more information, the styles for the calculator are here: style.css, style-hc.css, style-dark.css. Notice there are three styles for normal, dark and high contrast; part of the problem is that gtk.css does not have any way to know about theme variants. This would be easier to come up with a better solution if the CSS parser in GTK knew about CSS variables and media queries, but currently it does not.
And if you have bug fixes to the CSS, I am sure it would be appreciated to submit those upstream.
This idea is new for me. I have considered styles in ~/.config/gtk-3.0/gtk.css as a method to customize applications running on a particular computer.
In the Windows world, the customization is done with dialogs and menu settings. But Unix/Linux applications except some portable/multiplatform ones like Firefox do not typically provide those opportunities. So text files with cryptically looking instructions are the main way to do so. This is not limited to CSS. Compare altering code highlighting rules in Notepad++ and gedit 
At first glance, it makes sense to think that. But would you use a global CSS file to customize web sites running in your browser? I don’t think so, it would just break. The only reason anyone seems to think this works for GTK is because some people seem to use relatively few GTK apps with relatively stable styles. But that of course breaks too when an app changes its styles, or some app does not use gtk_widget_set_name in the very specific way that is required to make that work (and still may have issues anyway).
These are graphical applications with a fully functioning GUI toolkit, if there was a desire to make a good customization GUI then it would be done. But at least in GNOME, there is an understanding that adding tons more customization options either breaks things or is a sign that something is broken.
Actually a lot of extensions work this way, noscript, adblock, etc. They put all the rules in one file and just sort by URL. In fact the Dark Reader extension literally has one big file over 22,000 lines of CSS code for different sites that can be customized. It’s not so bad. Unfortunately we don’t have URL’s with GTK applications so it doesn’t work out the same.
Yeah there’s a balance that’s needed for sure. But developers can’t please everyone either. They’re making software that millions (?) of people around the world use. There’s no way you’re going to please all of them with static content, so providing for some level of customization is required.
That being said, since we can already use a global gtk.css file, it might also be nice for apps to just look in their ~/.config/'s directory for gtk-3.0/gtk.css or gtk-4.0/gtk.css file as well, or something…
You may notice how each of those has a GUI to disable it or modify the rules on various sites because they regularly cause sites to break. Using those extensions is signing yourself up for constant maintenance, I really would not call those a viable solution for most people. I am not sure which Dark Reader extension you are referring to, but having one giant 22k line CSS file to apply to every website seems completely unmaintainable.
No major operating system has the level of customization you’re asking for, because it is actually impossible to do this without causing everything to break all the time. Windows, Android, MacOS, iOS, you name it. It seems all the billions of users of those systems seem to be getting by without it. What they all do is provide some very limited customization like light/dark mode and accent colors.
This can already be done easily if you put the app in a flatpak and edit the file in ~/.var/app/APPID/.config/. But still it will retain all the other problems that I mentioned before. FYI there is a GNOME Calculator flatpak.
idk man i never had problems with noscript, and ublock works great too. so does dark reader,
I cannot say that is my experience, turning off scripts breaks a lot of websites I visit. Discourse still kind of works but it has severely degraded functionality. And sometimes with adblock, the website author detects it and intentionally breaks the page until you turn off adblock…
I tried to search that repository for CSS files but I don’t see any global theme, all I see is styles for the extension GUI.
Edit: never mind, the CSS customizations are here: darkreader/src/config at main · darkreader/darkreader · GitHub But this is still a relatively small number of sites, and plus this is not a normal CSS anyway. It is a custom format with some URL filtering. You cannot do that with just a CSS file.
I can follow your considerations, but I can’t share them. If I see it right, your main reason is that using gtk.css file is risky. This is true, but not enough because there are many risky tasks that are done nevertheless. E.g. system updates. Every OS update can damage the system. This is not a theory. I have here a Linux installation that was damaged by the last update: the GRUB updater wrote several files to a wrong location. This misbehaviour is well known but still not corrected (it occurs when the Linux is installed on an external medium like USB drive). Windows updates can also make the system not working anymore. Does this mean that we shouldn’t update software? Probably not. You need to make something that is called risk analysis and compare advantages and disadvantages of the analysed task and its neglecting.
I use gtk.css for activating arrow buttons of scrollbars that are disabled by default nowadays. Does it mean that I better should rewrite and recompile all the applications running on my computer for this purpose? Or, that I should make a custom theme, and this only in order to change one single detail. This is wasting of time and resources. And I can do lots of wrong things, so the risk is much higher than by using the gtk.css file.
In the GTK documentation on GTK_STYLE_PROVIDER_PRIORITY_USER we can read: “You should not use priorities higher than this, to give the user the last word.”
If the risks of using gtk.css were considered serious why the GTK gives such a power to the end user? It seems that the risk level is considered as acceptable.
As a matter of fact, this is probably true. But is this status quo what we want? Is increasing the Linux user base a wishful development or not? If not, everything is OK. But if this is something that we would like to achieve, then the conclusion is different. To some extent, Linux is still a “Do It Yourself” (DIY) thing. But a DIY can require a different level of skills. Basically we have 3 levels depending on how the applications can be customized:
(1) the developer level: changing an application requires changing and recompiling its source code.
(2) the power user level: changing an application requires changing text config files, incl. gtk.css.
(3) the common user level: changing an application (better: the behaviour/look of an application) can be done by using GUI (menus, dialogs).
Every higher level of required skills means less users. Now, Linux is somewhere between DIY for developers and DIY for power users. By proposing that recompiling is the only way to customize applications, we bring Linux back to the times when it was a DIY for developers only. I think that the opposite direction is preferable: making Linux accessible for common users.
I can not follow this part of the discussion to the full extent. Nevertheless, I would like to point to the fact that modern browsers provide a kind of a global CSS: the one that is applied by default (fallback level, e.g.: https://hg.mozilla.org/mozilla-central/file/tip/layout/style/res/html.css). This is the reason why a web page without styles is displayed in a different manner by different browsers. This can be considered as a kind of customization, but done in the opposite direction: the browser “customizes” numerous and very different websites found on the Internet.
No, it’s not just that it’s risky. It’s that it is guaranteed to break when an app updates its CSS. The way that it’s suggested to use it cannot possibly be tested in any meaningful way.
That’s quite different from your distribution having accidental bugs in the GRUB update script. They can absolutely test for those. My feeling is that they should not put out updates without doing enough testing.
No, if it’s a GNOME app then you would only have to rebuild gtk or libadwaita, and then rebuild other apps if there is breakage. That would be much more reliable. Despite what the documentation says, the app can still technically override PRIORITY_USER styles depending on how the CSS is written. Yes that might be a lot of work but so is constantly updating your gtk.css with hacks and workarounds for a styling system that wasn’t made to do what you are attempting to do with it. I used to do customizations like that too, but then I stopped after they broke apps one too many times.
That is not a proposal, it is just a fact: some theming bugs are complex and app-specific and you need a developer to fix them. That is true on every platform, not just Linux. Go look at iOS, there is no theme customization at all, and that definitely isn’t DIY for developers only. If you want a theme to be reliable and not break, then it must be maintained as part of the app and bugs in it must be considered the same priority as all other graphical bugs.
My point here is that gtk.css is actually not a good tool for what you call “power users”. It is only really good for developers to test and debug the platform theme. It is not a “setting” that users are meant to change nor is it a theming API. If you try to use it for customization then it has a lot of issues and it is also guaranteed to break in various situations. There are different ways this could be fixed, but the current status of things is not actually doing what you might think it is doing.
This seems to be an idea that showed up early on in the web but has not panned out and is now actively considered to be bad behavior. When making a web app for multiple platforms you absolutely do not want the browser messing with the styles. Do a search for “css reset” just to see how many solutions there are for this.
Anyway, this has been offtopic for a while now. I believe I already gave the answer to the topic: don’t do this. If you really think you need to do it, then do one of the following:
- start contributing to gtk/libadwaita/etc and help work on building an actual reliable theming API
- contribute upstream to the apps and convince them to have a theme setting (see GNOME Builder 43 for an example of how libadwaita apps can do this)
- maintain your own fork of gtk/libadwaita and of the apps (if you need complex changes that upstream doesn’t want)
- use flatpak and edit the
gtk.cssin the flatpak config folder, and be prepared to deal with broken behavior
Thank you for the very detailed description of the situation. It is now more clear, nevertheless it still sounds a little abstract for me. Here is a particular example, which perhaps makes it closer to the developer’s everyday.
In the main menu, I added a check box for enabling/disabling arrow buttons by scrollbars. The only thing, that it does is (un)setting a particular style:
.scrollbar {-GtkScrollbar-has-forward[backward]-stepper:1[0];}"
(it also checks whether the class name “scrollbar” is set; this is a GTK3 application)
The result is a mixed one. It depends heavily on the current theme. There are themes that offer special styles for scrollbar arrow buttons. In this case, it looks fine. But some themes apply default styles for all buttons instead and then it looks ugly.
The user needs two steps in order to enable successfully arrow buttons: (1) check the box in the menu, (2) select the right theme. If one knows what to do and what result is to be expected, then this can be done within a few seconds and only by using GUI. Provided, there is an appropriate theme, of course.
I see, that this method has too many preconditions. I can provide a full styling for arrow buttons, but I think that I can’t be sure that my styles would harmonize with theme styles. As a fallback, I considered a button that changes the gtk.css file by adding/removing the special styles for arrow buttons. Or, instructing the user, how to do it manually.
I must confess that I feel an inner struggle whether this way is a good one. But I don’t see just now what approach would be better, except providing a special build for every particular distribution (which I still try to avoid).
There is no long-term general solution. Either you don’t support alternate themes at all (because the stylesheets that commonly get called “themes” are not really themes, they are hacks injecting pieces of code that can change any widget in any app in unintended ways, including making the widget invisible or making it 100000px wide, or whatever) or you build the app to support the specific themes that you want (i.e. you build them into the app/libraries as a compile time dependency).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.