tl;dr: If you want to change how an app looks, you need a designer in the loop.
Over the past few months we’ve had a lively debate about “theming” in GNOME, and how it affects our ecosystem. In this discussion I’ve found that there is a divide between people who design and/or develop apps, and people who don’t. I have yet to see an app developer who thinks the current approach to “theming” can work, while many people who aren’t app developers are arguing that it can.
After a few long discussions I started to realize that part of the reason why there’s so little agreement and so much drama around this issue is that we don’t agree what the problem is. Those who don’t work on apps often can’t see the issues with theming and think we want to remove things for no reason, while those who do are very frustrated that the other side doesn’t want to acknowledge how broken everything is.
The basic issue we’re arguing about is whether it’s possible to restyle applications automatically, at scale, without breaking them. In this post I’ll try to explain why I think that it isn’t possible, and why trying to do it is hurting our ecosystem.
There are no themes, just CSS
A fundamental misconception a lot of people have is that GTK 3 supports theming. This is not true, as there is no clearly defined theming API. There are CSS stylesheets, but they were only ever meant to be used by the platform and app developers. The platform stylesheet is called Adwaita (“the only one” in Sanskrit) for a reason.
However, some people (inlcluding major distributions) have been using custom stylesheets as a hacky approximation of “themes” for so long now that nobody even remembers that they are not a real theming API.
Since CSS is a huge API surface, which is used by both app developers and “theme” developers, it’s very easy for the two to conflict. This leads to apps looking broken unless you manually do QA for every app/theme combination.
“You’re exaggerating, it’s not that bad.”
One of the most frustrating things about the current situation is that to users, it looks like it almost works. For the most part, third-party themes look and work okayish, there are just a few small bugs here and there. A button with too little contrast, an underline clashing with a border, a really large loading spinner. Not that big a deal, you’d think.
However, this view of the situation misses a few really important realities:
- App developers are doing a lot of bug fixing to account for “theming”, because people complain to them when their app is broken on certain distros. The current situation essentially forces developers to fix bugs for setups they never intended to support in the first place. They’re not happy about it, but they’re doing it because they don’t want their users to have broken apps.
- App developers are trying hard to not do anything innovative or visual in their apps, because they know it will break with other stylesheets.
- “Theme” developers are fixing a lot of bugs for edge cases in individual apps in their stylesheets. Of course, this is a never-ending task because as soon as a new version of an app is released, something will very likely be broken again.
All of this only kinda sorta works because we have very few apps. If we ever hope to grow our ecosystem past a few dozen apps things have to change, because maintaining a “theme” gets less sustainable with every new app.
There is also the question of what your definition of “broken” is. Some people think that things like these are acceptable:
I believe this is nowhere near ok. App developers put a lot of effort into making sure their apps look and feel right, fixing bugs, and doing QA. Having distributors change their apps (often in ways that break things) with no QA before users get to experience them is developer-hostile, and would be unacceptable in any other context.
Can you imagine Samsung restyling every third-party app on their phones, without testing them, and when Instagram complains that the text on their buttons is illegible Samsung just shrug and say “Sorry, but branding is very important to us. Why don’t you change your app?”.
“But it’s fine as long as you follow best practices!”
This is a common sentiment among some people. “If only app developers followed best practices, used CSS variables, and derived their colors from theme colors, everything would be fine”, the argument goes. While it’s true that these things are important and make apps more flexible in terms of appearance, this doesn’t come close to solving the entire problem.
If every app only used default GTK controls, in very simple layouts, with no custom widgets or in-app CSS, then best practices would perhaps be enough to prevent apps from breaking. But the reality is that a) this is not the case, and b) we really don’t want it to be the case.
Human Interface Guidelines are just that: guidelines. They have to be implemented manually, they change and evolve over time, and the best apps on any platform push their boundaries in some places and experiment with new patterns (which then sometimes make their way back into the HIG).
This kind of experimentation means that it’s impossible to “theme” apps automatically. Visual design and interaction design are very closely linked, so if you want to change the style, you need a designer to actually think about what a widget should look like.
For example: How should the Pop theme know what a “flat” variant of the new Nautilus path bar should look like? It’s impossible to do this automatically, because it’s a new pattern.
This is not a rare situation, even among core GNOME apps. Many of the apps I’ve personally worked on have their own equivalent of the Nautilus path bar. And that’s the way it should be. Apps have different needs that sometimes require custom solutions, and this experimentation is good for the ecosystem. However, it also means that automatic restyling is impossible.
“But what about Adwaita Dark and High Contrast?”
The point that the dark and high contrast variants of Adwaita can be seen as GTK 3 kinda sorta supporting themes is technically accurate, but misguided. Adwaita variants may technically just be different stylesheets, but this is just an implementation detail. There are very clear differences between them and third-party “themes”.
- They are very very close to Adwaita code-wise, and therefore much less likely to break.
- There’s a finite number of them, and they are part of the platform. This makes them a tangible target for developers to test for and support, which is completely different from third-party “themes” which just apply random CSS to every app without any QA.
- They are part of the same design language, so they require very little extra work to adapt to from a design point of view. If you follow the best practices mentioned above, often no work at all.
“But what about consistency? I want all my apps to look the same!”
“Consistency” is a word you hear a lot in debates about theming, but it seems to mean different things to different people.
To some, consistency effectively means “everything should use the same colors”. This is relatively easy to achieve for some apps, even across toolkits, if you simply provide a “theme” for each toolkit.
However, this “consistency” is very shallow. Just because a Qt app uses the Adwaita colors it doesn’t automatically fit in with the GNOME platform. UI patterns are much more important, and they can’t be changed with theming. There is no magic that can redesign menu bar apps with header bars.
Real consistency can only happen by design, and requires the app developer to build it into the app at every step. If you want all your apps to look the same, only use apps built for your platform’s HIG. “Fixing” apps after the fact with theming isn’t really making your system more consistent, but it’s hurting app developers a great deal.
Of course, even the very shallow “everything uses the same colors” consistency is impossible to enforce across all apps and toolkits. Apps like Blender, Telegram, or Steam don’t respond to system theming at all, and even Firefox and Chromium only do so in a very limited fashion.
“But users *want* themes!”
“Users” want a lot of things, but just because you want something impossible that doesn’t make it possible. In this case, it’s important to be aware of the costs of giving complete visual freedom to “themes”, both in individual app developer effort, and chilling effects on the ecosystem. If given a choice between customization and more, better apps, I’m confident the majority of people would prefer the latter.
Would it be nice if there were a way to be able to restyle every app to make them look like Material Design, or macOS, or Windows 95, and have them all look as if they were built for that style? Absolutely! I would love that! However, as I’ve tried to explain in this blog post, this is simply not realistic.
So, what can we do?
As the recent discussions have shown, talking about solutions before we agree what the problem is isn’t very productive, so for now I’m mostly interested in making sure we’re all aware of the problem and its various facets. There are several different stakeholders with different perspectives on this issue, and making progress will mean making some hard choices. At this year’s GUADEC we had a Theming & Ecosystem BoF where we talked about a number of potential directions, and I hope we can move forward on that path.
No matter what we come up with though, I think it’s crucial that we start taking the needs of app developers seriously. Developers are the lifeblood of any platform, and we’ve been treating them very poorly. If we want to grow our ecosystem and actually compete with other major platforms, we need to fix that.
Note: The examples in this post have been chosen because the themes in question ship with major distributions, so app developers tend to get complaints about them. It’s not my intention to single them out, this problem applies to all third-party themes equally.
Very very on point. Thanks for writing this!
Yes, the status quo is not OK. I’m tired of getting bug reports from users of custom themes, who expect me to fix the problems, even though I don’t know CSS and certainly don’t know how to fix their problems. So I close the bugs, and users get frustrated, and who wins from this, really?
Maybe I have developed solution.
Totally splitting application logic from UI. Libgreattao is library, which can achieve this. It uses Qt5, Gtk2+, cui and text shell backend. It loads correct backend on the fly.
Application tell: I’m application to burn CD-rom, create (please) two file-manager view, one actions view, create /actions/burn, /actions/close into actions view and /file/a, /curr_path in first file manager view. In next step set /curr_path of first file view onto /home/slawomir. Libgreattao process everything and generates GUI/CUI/Text shell.
User, OS Vendors or even app vendor could edit view controls, so for example /curr_path could be single-line edit or multi-line edit. Files could been displayed as buttons or as items in file list. User could order to display some actions on top of window and rest on bottom.
Why I describing this? Because this provides a way to move UI modeling from App developers. Why each CD burning tool couldn’t look the same? Why look & fell of burning tool couldn’t bee changeable and why user/os/DE vendor couldn’t provide custom GUI?
I don’t have much time to develop libgreattao as much as I like, but I will help in correct bug, etc.
You basically created an abstraction layer over toolkits. The problem that was solved is not the problem being discussed here.
Yes. That’s abstraction layer, but it isn’t normal toolkit. Problem will be the same if my solution just allow to create buttons and other widgets. In my solution developers shouldn’t create widget (they don’t have to), but DE/OS/My library vendor have to.
In other words, that’s solve problem by moving responsive about theming application onto DE/OS/Libgreattao vendor or User. Developer still can create new window class (in /app_vendor/app_name/app_version/window_class/wnd_cls_version) and others can override it.
There are other ‘logical’ issues with theming in general, say I want a different control to look like a button, having a ‘fixed’ UI to aim and by using CSS it’s a joke. Just copy and paste the button style and you’re done. Think about how hard it gets w/o using CSS and aiming at a random look.
I used to work for a proprietary software vendor that releases its application on multiple platforms. Many many years ago, they switched to Qt from Motif for their Linux version. (I pushed for Gtk, but in the end I was happy for it to just not be Motif anymore.) This vendor baked in a Qt theme to ensure that user themes wouldn’t be applied to their product, because themes are a nightmare for third-party developers.
That sounds awesome, but it creates an even bigger problem. Take WPS Office for example. They have a QT theme baked in, but if you are using a dark GTK theme at the time, many labels, buttons, and menu’s become white-on-white, because of the insane mixture with the WPS theme and the current GTK/QT theme. I still don’t know how to solve this problem!
What about Gnome around version 2.28? The theming interface of Gnome 2, while very baroque, had stabilized, and there were plenty of high quality themes.
I think it comes down to the authors of apps to use best practices when creating custom controls, not so much the authors of the themes. For example, there should be an official way to draw a “button-like” control, a “well”, a “separator”, and an especially detailed theme could override things more specifically, like the pathbar.
At least for me, themes *are* an important selling point for a desktop, and I was pretty disappointed that they were no longer supported by Gnome.
Did you read the article?
The “good practices” argument you reiterate is specifically addressed in it.
Why wouldn’t implementing a theming API work? Honestly curious.
Is there a specific reason to not support basic theming like colours and styling on standard GtkButton used and provided by Adwaita. Should anything custom not provided by Adwaita break, the onus would only then be on the app dev.
A theming API of some kind is certainly one of the possible solutions.
However, in order to avoid breakage with custom widgets, this API needs to be either very limited (think macOS accent colors), or opt-in (apps have to explicitly support a theme), or both.
There can be a middle ground solution to this. The first question to ask is: why users want different themes in the first place?
The answer is that each person has different tastes, for example I never liked the colours of Adwaita, neither the light nor the dark ones. My solution has been to use the Greybird theme, since the very beginning of Gnome 3. That is an unofficial theme, but it customizes the little details that I don’t like.
So the middle ground solution could be to have the elements that have fixed dimensions, fixed padding, and fixed fonts (the font issue opens a whole new can of worms), but with CSS you can customize background colours (that can become gradients and/or images), borders (not the thickness, but the radius and the colour), and nothing more.
With that you have a guarantee that each new element is consistently placed, as there are no changes in dimensions, border width, padding and font metrics, and the users are happy that their theme matches their taste.
I like this solution. I was thinking the same while reading this post. The only problem I could see whit this theme support is, if an application only has partial theme support you may end up with bright text on a bright background or dark text on a dark background. This problem happens a lot in web browsers. (Try using a dark GTK 3 theme, then try to type something in the search bar of YouTube. It will most likely be unreadable.)
> happens a lot in web browsers
That happens only in Firefox (they even have a 20 year old open bug about it). Color spilling should just be removed in Firefox.
Thanks for the explanation Tobias.
Because so many GNU/Linux users are on Ambiance, though, isn’t Ambiance (though that distro is now changing its theme) ‘part of the platform’ in the sense that app devs tend to target it (though you have the real figures, maybe they don’t)?
Also, don’t app developers already have an inconsistent target on GNU/Linux in general because there are multiple desktop environments and GNOME dramatically deviates from the others with header bars, calling all non-HIG apps to appear ‘non-native’ as you said? So is HIG at fault for providing a bad target for app developers? How about, unlike other desktop environments, removing the system tray and the dock? Did those decisions treat app developers well, given that app developers expect those parts of the desktop environment to be there?
At GUADEC, what were the possible solutions laid out / where can we read them and how has the debate on solutions progressed since then? I think people are worried because it sounds like GNOME are going ‘bah, the status quo’s not ideal, let’s force everyone to use Adwaita, take that Ubuntu! Bye-bye Ubuntu branding mwahaha! Users who hate Adwaita? Suck it!’ I know this isn’t the impression you’re trying to give, but I think it’s how the idea is still coming across, and I wonder if a lack of self-awareness is somewhat to blame – GNOME makes decisions that are unfriendly to app developers all the time (because they change the GNU/Linux target), see above, so why make this particular decision which will, in particular, damage Ubuntu’s objectives? What did Ubuntu devs who are also GNOME Members say on this at GUADEC and since then?
I was that meeting, and definitely this isn’t the impression we want to give. The biggest problem is that there are different platforms (think GNOME, elementary, etc) that app developers can target, and these platforms have different sets of “theming” options. Nobody sat down to properly “document” those in the form of CSS variables and call it an API, because nobody knows the real depth of this hole. So either we start extremely small (only allow changing a few colors here and there) or just state that themes aren’t a thing and you’re on your own if you want to change that.
But what I do know is that it’s frustrating and enraging to see distro and theme developers breaking my applications. It took me years to make them look and work correctly, and minutes for somebody else to break it. And that’s why I am considering forcing Adwaita on my apps.
This sounds a bit…selfish. While i can appreciate you’ve put time into making apps look the way you want, you can’t force users to not have control. The whole point of opensource is that the user is able to do whatever the hell they want to with it.
I’ve been using linux for around 15 years, and theming/customizing has been a core part of that. Gnome 3 feels like the developers saying FU to users, and the reaction you get when you create a post like this is justified. We aren’t on Windows/Mac, this is linux, and we do things the linux way – ie take something and modify it as the user sees fit.
If users break your app, its on them. You shouldn’t get to dictate what a user does with their own system.
Also what should users who hate Adwaita do?
> The whole point of opensource is that the user is able to do whatever the hell they want to with it.
Yes, but that doesn’t mean developers must allow every possible customisation.
It means that you’ve got the source, so if Georges makes GNOME Calendar use only Adwaita, you can patch that out and recompile your own version.
> If users break your app, its on them. You shouldn’t get to dictate what a user does with their own system.
The problem is specifically that everybody believes we have theming capabilities, and that it’s supported.
So when users break your app, they come to you and open bug reports after bug reports about how your app doesn’t work with $theme.
And they expect you to fix it, and they will get angry and insulting if you reply that you won’t, because you’re only interested in supporting $theme_you_tested.
This whole article is an effort to shift these expectations, by showing that it can’t be supported.
If we could get to a point where indeed users accept that “it’s on them”, then we wouldn’t need any action.
But we won’t get there, because too many FOSS users are entitled jerks who believe FOSS is about “the devs must do what I want for free and listen to me!!!”
Thanks Richard for sharing your opinion but calling someone selfish in that situation feels very unfair.
You might have strong feeling about some software, but nobody is forcing anything on you. As long as it is open source you can do whatever you want with it. Limiting configuration or theming options isn’t in any way against freedom that open source gives. I don’t think that throwing theming/configurability with opensource values and Linux vs Windows/Mac debate into one bucket brings much value into the discussion about global theming.
> If users break your app, its on them.
Exactly. Except it’s not users breaking them, it’s distros. And except users of those distros then come into bugtracker and ask to fix those things. The question is who is responsible for fixing broken themes? Theme developers or app developers?
The primary reason why I use a theme other than Adwaita is that every time I switch to Adwaita everything is *huge*, especially the HeaderBars are really really tall. The CSS margins (I think?) are much too big for me, compared to other “themes”, or even Windows or Android UI, tc.
Since “themes” are not the way forward, would it be possible to support a variant of Adwaita for this (maybe Adwaita-condensed)? Otherwise I might have to wait for fractional scaling to finally work and set everything to be 0.75x of the original size …
Themes is what keeps me using and recommending GNOME. You have to face the fact that there isn’t a “one size fits all” solution when it comes to themes.
In Android, although you have a series of standard widgets, most of the developer teams have a design group that takes care of how the application will look, overriding the default theme for widgets or not using them at all so the branding can be done at levels like launcher, system settings and special applications. For big apps, this design teams keep the application up to date with the latest design trends so they never look dated and they have a style on their own.
Mac doesn’t support themes but they have a big design team for their default theme and they are able of setting fashion trends so their theme looks elegant and modern by default and most people don’t feel the need to change it. The same, to a lesser extent, goes for Windows.
When it comes to GNOME, the default theme looks dated by default. It’s ok-ish for widgets but extremely dated for icons so users look for more modern themes like Arc or Materia or Adapta that follow the latest trends and we make our desktop look better. I might not like the latest Ubuntu theme but I must admit it looks as something designed in 2018. I can’t say the same for Adwaita widgets and icons. If we had a better looking default theme, like MacOS does, there wouldn’t be so much need for theme designers to try to get GNOME looking like a 201X desktop environment.
You’re mixing two distinct things in Android.
1. Yes, OEMs customize Android. However, it doesn’t affect third-party apps unless they explicitly state they support themes by using DeviceDefault theme instead of Material (or Holo for 3.x/4.x era apps). And Google has extensive compatibility tests that specifically dictate what manufacturers can and cannot change (one of the requirements is that OEMs cannot customize Material and Holo in any way, only DeviceDefault[1]), and they have to pass those tests if they want to get Google Apps package, including Play Store. Now, there are also custom ROMs that have themes, but since you flash Google Apps manually there anyway, any app developer can say since it’s not a Google-approved platform, it’s unsupported and you’re on your own.
2. Yes, many/most third-party apps use custom styles. And is exactly the thing that unrestricted theming interferes with. :) All those apps use Material theme that is guaranteed not to be tampered with by OEMs. It was a _huge_ problem before Android 3.0 when there was no DeviceDefault/Holo distinction and OEMs did whatever they wanted with the theme.
1: https://android.googlesource.com/platform/cts/+/master/hostsidetests/theme/README#18
Tobias, you raise some very good points here. I’d be interested to hear more about what conclusion you guys reached at that Theming & Ecosystem BoF.
I think the problem with theming is that you can easily fall into extremes. Straight out disallowing theming is equally as bad as allowing to theme everything. I think the correct thing to do is compromise between these two extremes by allowing a number of key parameters to be changed, while disallowing too much customization. Good examples of this are WP7 where you can select a dark or light background and an “accent color”. Another one is the ambiences on Sailfish OS where you can pick a background and a color and everything else is calculated from these.
I think this direction would provide a liveable middle ground that suits everyone. For example, allow themes to just change a few key colors (background color, accent color) and key attributes (like, flat or non-flat), and then have some logic that calculates the rest of the styling from these settings.
What do you think?
These are certainly possible solutions to be discussed. Some kind of color API could be unobtrusive enough to allow for some customization (Ubuntu could make things orange :P) without breaking custom widgets.
Then again, they could already do that right now by changing a few colors in Adwaita, but they’re making a whole custom stylesheet instead. I think this isn’t really a technical problem. As long as people (especially distros) don’t realize how harmful theming is to app developers, this situation is unlikely to improve. If and when they do, finding a technical solution will be comparatively easy.
Tobias, I think that a good way to implement theming is to provide an API to both theme developers and program developers. For theme developers, it would give them the power to change the look and feel of GTK as they are used to through an actual documented API while preventing them from breaking the underlying system components. Program developers would be given the various information for the theme to use within their program’s routines if they wish, as well as the ability to specify their own theme changes that only affect their program (up to defining their own complete theme for the program’s window if they desire.) If users are given the option to disable program-specific themes, they should be informed that “this is not officially supported, please do not report bugs that exclusively appear with this turned off.” I believe this would satisfy all parties in the argument. For an example of this implemented successfully, look at the Visual Style scene for Microsoft Windows XP, Vista, and 7.
Of course, this would all apply to GTK+4 and GNOME 4 since GTK+3 is frozen and stable, and the next major version is a great place to tackle all the other major issues like the extensions “API” (which like themes is not an API, are basically monkey-patching, and can crash gnome-shell, something which isn’t good on wayland) and the multi-threading aspects that make gnome-shell perform slowly on wayland. Just want to verify that is what you are talking about… correct?
Just some thoughts.
1. CSS as a theming API is indeed broken. Just look at your post on Planet Gnome, which attempts to restyle it.
2. It would be interesting to see the opinion from KDE camp on theming their applications.
3. Other desktops (and I mean desktops, like MATE and XFCE, not distros like Ubuntu) are also a major source of toolkit themes. However, your examples of breakage are focused on distro-related themes. Did you get any complaints about the look and feel of your applications from the users of these desktops?
Qt have a limited API, derived from CSS called QSS, Qt Style Sheets.
There is a list of proprieties you can customize for each widget[1].
A more radical theming is available trough plugins written in C++[2], like Fusion (Qt), Breeze (KDE) or Qt Curve e Kvantun (community).
These are Qt options, and can’t be disabled, system wide, by Plasma. Each program can hardcode a style plugin or a QSS file.
1 – http://doc.qt.io/qt-5/stylesheet-reference.html
2 – http://doc.qt.io/qt-5/qstyleplugin.html
So effectively, apps opt in to theming?
Also, how does Qt deal with custom widgets (like in the Nautilus pathbar example)?
Run an Elementary app, e.g Tootle, on GNOME, and observe how broken it is.
On the other hand, run a GNOME app on Elementary and you’ll see some breakage as well.
So yes, things do get broken between desktop themes.
To fix this, it’s important to look at the needs behind theming. Here’s what I think they might be:
For home users:
– accessibility
– fitting more elements on screen
— there might be different needs behind this: could be a personal preference, could be an app where some commonly-used button gets hidden in an overflow menu, or could be unusable apps on small form factors (having lived with a netbook as my primary device for years, I can tell you I wouldn’t be able to use Inkscape were it not for the setting to make it more compact)
– visual preferences
For distro makers:
– branding
For developers:
– branding
– custom interaction design
How might one solve each of these?
Accessibility: In terms of theming, this only seems to revolve around color contrast. As mentioned in the article, this can be solved by a high-contrast adjustment of the default theme baked into the toolkit. Another solution would be to make the default theme high contrast (as used to be the case for Windows’ Metro).
Fitting more elements on screen: If implemented with a theme, it seems very liable to break apps. It’d be preferable to give control of this to the developer. Apps where this is needed could implement a compact view and present it in settings. And the toolkit could make it easy to implement such a thing.
Visual preferences: Again, liable to break things. There are ways to give app developers control while making the number of possible user optimizations managable. The toolkit can include APIs to make it easy to implement:
– A separate dark theme
– A secondary color hue that the user can customize
– Wallpaper-based theming
That might not seem like enough. However, it’s closely related to distro and app branding. For devs, it’s important to be able to reflect their brand while fitting in with the platform. Ideally, the toolkit should allow them to easily:
– Use custom typography
– Use brand colors throughout their apps
– Use custom iconography
For distros, the requirements are essentially the same, except it applies to the shell and basic default apps. It’d be good if these apps made it easy for distros to tweak their look, but the burden of doing the QA should fall on the distros themselves. Maintaining a single theme on a handful of apps shouldn’t be too much of a burden. (And if it is, distros can just theme the shell and be done with it.)
This ties into the user’s visual preferences. If a user prefers Ubuntu’s style, they’re welcome to switch to Ubuntu (or install their themed apps and shell). Non-platform apps would have their own distinctive look, but one that follows platform standards, is cohesive, and carries across a distinct brand.
None of what I’m suggesting is untested. In fact, it’s been working quite well on mobile platforms. Google’s recently expanded Material Design guidelines serve as good inspiration for giving developers the power to change their apps while maintaining cohesion on the platform. You can see it in practice by comparing Google’s apps, default platform apps, and third-party apps (like Twitter, Facebook, or Adobe’s apps) on Android.
On the concept of themes. From a Graphic Designers perspective, orange, purple and brown are a triad of tribulation. It’s a hideous and annoying combination of colors that should be banned. It makes anyone with artistic knowledge want to vomit. Whomever guided Ubuntu on this ridiculous notion was probably some African giraffe. If I cannot use Arc from the repository as a result of your argument I will switch to the more elegant Elementary or worse yet Fedora. Orange, Purple and Brown are for Halloween, not a desktop user interface. I might even switch to Mint…
Your reasoning is rather GNOME oriented. Especially knowing on how widely used Qt is for making Linux apps. An average Linux developer isn’t all that interested in developing applications for GNOME exclusively on Linux. Therefore if GNOME would need a special treatment for the application to look good in GNOME. I could imagine less and not more applications made for GNOME would be the outcome. Therefore the day you remove theme support for GNOME. Likely that will be the day when majority of Linux apps will start to look bad on GNOME.
Therefore i don’t realistically see for that to happen anytime soon.
I have no problem with only one general theme If everything will works fine and better I would say yes, let it be only one. Just one thing I can not stand on Gnome and that is not completed icon set. I must install obsidian, or Suru++ icon set, because default one is down not have thousands of icons for apps and other type of icons. Also some colorful cursor like circle rainbow for waiting is much better than adwaita cursor.
I tried to install many themes but somehow I always activate adwaita after all. I saw many problems with gtk3 themes, I have a problem with non gtk apps as well for example the most usable software on PC Firefox have really big problems with dark themes, input buttons and fields are not readable and many many wrong things.
But this is now question what theme should be by default, Adwaita is not the perfect one. I would like something more clear and modern, I like macos theme with blur effect, that is perfect for me, now windows have nice blur effect in settings and I can’t believe Windows made something beautiful but yes, that is also nice solution. I would also want rounded bottom corners, or all sharp corners, I don’t understand only top corners to be rounded..
So why not having one default theme but with such engine that will allow you to change main color, opacity value, all colors for widgets, all options for customizing this one theme. I would like live, colorful theme, be inspired with nature, africa, india,..
Yay for pragmatic Linux development!
Indeed, it is time we took a hard look at many of the “nice to have” features in Linux and cut them back to the point we can achieve the reliability and consistency expected in modern operating systems.
We can probably hit 80% of the needs of “theme” users with some very basic customisation points, CSS is just dramatic overkill.
Due to theme fragmentation, there is no clear definition what Gnome looks like in 2018. Obviously the official theme is Adwaita, yet on countless unofficial tech blogs screenshots of Gnome software tell a different story. GNU/Linux DE’s are already fragmented to a point which is beyond confusing to any average user.
It is very easy to see what MacOS, or Windows looks and feels like from screenshots from users online.
Yet with 1000’s of user themes for Gnome, explaining what the GNU/Linux Gnome system looks like to a non-user is almost impossible.
I feel however that this is occurring for a reason. Users are not waking up in the morning and thinking: “lets mess up the desktop again”. Rather people are genuinely wanting to experience a desktop that reflects their aesthetics.
If it would be possible to move the current ‘hacks’ slowly into an API, (one that respects developers and allows modest theming – if not only colours to begin with) then I would strongly suggest to go down that road.
An alternative may also be to create more official themes, ones that reflect the very best of current unofficial themes. (I am not talking about creating 100’s of themes, possibly 1-2 extra).
Possibly a more pragmatic short term solution (and a tad controversial) would be to create a more streamlined version of Adwaita, which may convince users to stay with the official theme.
I think its very complicated, as its been mentioned in this great article. Removing themes isn’t possible, as theming is currently a hack already. So how does Gnome go about ‘disabling’ themes which are already technically not enabled?
Full disclosure: I don’t personally use Adwaita for Gnome, opting for a flatter theme called Macterial. I find that (for me) it takes up less room, and is easier to see information.
However it has taken a long time for me to find a theme that doesn’t break usability with Gnome, (which is a deal breaker for me). I prefer themes that are simple (in the technical sense) and won’t cause display issues.*
I would much prefer to not spend time theming the OS, as I never have to worry about MacOS, or Windows. Yet ironically one major aspect to me not wanting to use Windows is that I don’t like the theme. (I know that this is petty, but I find it hard to see information clearly, visually many aspects are cluttered, especially in Explorer).
Possibly a re-imagined Adwaita could convince many users to drop ‘hacked’ themes altogether. (One positive is that Gnome has a very flexible CSS layout engine- which is the reason for this problem in the first place).
This could also be a moment to bring the community together, maybe even having a design competition, as there are already so many users hacking on unofficial themes, some of these users are UI/UX students / professionals.
One only needs to look at: https://www.gnome-look.org/ to see the vibrant community that has sprouted out of this hacking. It would be fantastic to engage these users and community (possibly on a different platform) as a task-force to generate a UI which is less prone to being replace.
It would be fantastic to channel this community in a way that respects developers, gives a solid user experience, and allows users to be proud of their desktop (which I am sure that they already are).
Developers are incredibly important, vital, and above all else paramount to GNU/Linux’s very function. Anything that gets in the way of what they are doing is not OK, and needs to be fixed ASAP.
*as of this post Macterial official is broken when displaying the File-Path-Bar in Gnome 3.30.1. I quickly fixed my local version.
I couldn’t agree more.
If you look around a lot of gnome users actually like themes very similar to each other, basically Arc or Materia-based ones.
I think that Adwaita should get a refresh, trying to be more modern and flatter (like android, windows, mac… everyone really).
The contest idea is great and I think it would please the community.
Since themes can’t actually be removed I think this is the only way which makes sense
The real solution is to offer an API for theming. QT offers this via several methods, including QT stylesheets. I would recommend GTK devs have a look at how they do it.
An API won’t make everything possible, but will help with many of the issues highlighted here. It will also make it easier for theme creators to do their stuff, especially if the API is kept stable.
Remove theming in GTK at your own peril – people really like theming, and software remains relevant as long as users use it.
I think its unfair to the hard work of the Gnome team to have to not only develop a default theme, but also develop a rock solid theming API, and keep it running well.
This is something that Tobias has pointed out is not even available in MacOS & Windows.
The best short term solution I can think of is to seriously consider improving Adwaita, and listening to the community. Very little of Adwaita’s issues are usability. For me the largest problem is the extra large title bars.
If Adwaita were improved, streamlined and spruced up a bit, I’m sure that the decision to remove theming would be less controversial.
Tobias, can you let us know if any update is planned? I have noticed that their are new Icons designed with the updated design guidelines. I can only guess that Adwaita will also receive an update to reflect the guideline changes.
A big reason why Adwaita hasn’t really kept up with the times is simply manpower. A platform stylesheet is a very complex beast, and it’s mostly being maintained by volunteers (shoutout to Lapo!).
In going about redesigning it there are really hard questions of contrast, legibility, and accessibility at every step, which many third-party themes simply ignore. We can’t (and don’t want to) do that, which makes this a very hard problem.
There’s definitely the intention to modernize Adwaita, but with the current resources it’s hard to say when it will materialize. That said, if you’re interested in shaping the look of the GNOME platform, there’s never been a better time to get involved ;)
Thanks for the reply Tobias. I do hope that Adwaita gets a refresh soon. Especially considering all those amazing new Icons that look so great!
gtk2 did this, also why are we chasing Windows and Mac? We’re on Linux.
Android supports theming using substratum without issue. Samsung skin their phones.
Samsung doesn’t skin every third party app, and theming was buggy in the GTK 2 days too (at least according to the GTK devs, I wasn’t around back then :D).
It’s simply impossible to have a large ecosystem of apps with custom widgets AND themes. No theming API can do this, because custom widgets need manual work to adapt to a different style.
What about refreshing the Adwaita “theme”?
It’s true that noone among Android, Windows, macOS and iOS supports system wide themes, but they all look quite modern and they were refreshed in the years (especially in 2013-2014).
Adwaita should get a restyling, becoming more minimal and flat, like every other platform, maybe even offering a “compact” version… And please replace those icons, they look like they’re from the 90s.
Just look at “Materia” theme by nana-4. It basically doesn’t break anything, it’s balanced, minimal and modern and it also offers a compact version, why can’t the Gnome default be something like that, in 2018?
I’m aware that this is mostly just a reiteration of other people’s thoughts, but I might as well take a stab at it anyway.
I can completely agree that the current theming system is incredibly flawed, but switching theming overall would be awful as well. Perhaps we could start work on a new theming API—which, as pointed out, would take a while—and in the meantime declare current GTK themes as unsupported, shifting the weight of compatibility issues to theme developers and users. I’m sure everyone would be delighted if we were to have a brand new theming API by GNOME 4 or 5.
I still only speak as a user for now, but I’d be happy for that to change.
Thanks for the well-thought-out article, Tobias.
I would like to respectfully disagree. I’m an app developer and I don’t recognize myself in your description of what “app developers” think and want. I have no problem just closing or redirecting bugs that users open, that are actually the fault of themes. Or even working around them on occasion. Users generally are quite understanding if you close their bugs politely, sympathize with them, and tell them where to report their problem instead.
I agree that it’s not realistic to expect all themes to apply equally well to all apps, but I think it is realistic to shift that burden to the theme developers.
Themes are not only about people modding their system for fun. Many accessibility features depend on it. GNOME is known for its friendliness to computer users with special needs, and just one Adwaita High Contrast theme doesn’t necessarily fit all those needs.
I don’t agree at all that this is even close to a bottleneck for growing our app ecosystem. How many app developers have you heard saying “I would love to make X app, and I have time for it, but I just don’t want to deal with theme bug reports?”
Finally, I think the theming community is traditionally a place where GNOME contributors have started out getting interested, honing their skills, and going on to contribute more prominently to GNOME. So there are social reasons to keep nurturing that community, as well.
> I agree that it’s not realistic to expect all themes to apply equally well to all apps, but I think it is realistic to shift that burden to the theme developers.
We’ve been trying to do that ever since 3.0, but evidently it has not worked.
This is not primarily about individual users tweaking their system, it’s about what distributions ship by default. Users may not even know “theming” is a thing, they just see that their apps are broken and go complain to the app developer.
> How many app developers have you heard saying “I would love to make X app, and I have time for it, but I just don’t want to deal with theme bug reports?”
I’ve worked with many third-party app developers in our ecosystem, and the reason why I’m interested in solving this problem is because they are all very frustrated with this. “LOL look how broken our app looks on Ubuntu” is a meme in that community. That’s a terrible developer experience, and though there’s no data on this, I’d be surprised if there weren’t chilling effects.
> Many accessibility features depend on it.
I explicitly mentioned accessibility in the article, and how that’s completely different than replacing the system stylesheet with random CSS.
> Finally, I think the theming community is traditionally a place where GNOME contributors have started out getting interested, honing their skills, and going on to contribute more prominently to GNOME.
Again, this is not about the “theming community”. It’s about making sure app developers have a reliable API to depend upon and QA against, so that users can have non-broken apps. If and how that would impact users who want to tinker with their system depends on how we choose to tackle that problem, but has nothing to do with this article. I explicitly didn’t discuss solutions here, and I don’t know why some people seem to be reading “let’s remove CSS from GTK” into it.
Fundamentally, this is a social problem: All we need to do to fix this is get distributions to ship the platform stylesheet, and tinkerers to file issues against “themes” rather than apps. If we can do that, we don’t need any technical changes at all :)
Hmmmm… ok, I get it – it is a hassle for developers.
But honestly – no matter how awesome I think GNOME is, I also have to admit that without theming option I’d be looking elsewhere. Adwaita is not awful – but also not really nice, with some parts that really do not make good use of screen space (extreme padding fe).
Yes of course you can say that you don’t have much in terms of theming on Windows or OSX. But those companies pump quite a bit of $$$ to get good layout / theme. I don’t think GNOME project is willing to spend enough cash to hire designer that would do a good job, nor I think it has one in its ranks (at least judging by what has been released so far). Not that it is not possible – Elementary is a prime example of absolutely beautiful theming in OSS world. There are also quite a couple of folks that created super nice GTK3 themes.
And you really can’t tell that the looks do not matter. They actually do – they not only make using an OS a more pleasant experience, but good designed theme makes it more readable and accessible.
I’d understand if you limit theming a tad just to make things more sane. Working on a better solution (even if it requires more work) would be even better. But lack of theming is a no go in my book.
Maybe everyone should just go back to the time when everything actually worked, Gnome 2, getting rid of theming? even Windows 10 can change the whole color of the UI,
Greetings from the future.
MATE (Gnome 2: The Sequel, the “what people wanted”, the “don’t fix what’s not broken”) is stagnated.
Gnome is still progressing.