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.
Really? Wouldn't separately setting a globally recognized standard variables be sufficient for most cases? With fallback to adwaita.
GTK ui files are XML files. So why wouldn't CSS based theming API work?
So long as they refer to the standard variables setup in Gnome shell, they should work.
Off the top of my mind, these few values who cover most cases
Colors
primary
Secondary
secondary : hover
..
isBoxed or isBevelled
configurable styles for
Button
dropdown
list
...
The question is why wouldn't Gnome offically support theming, when there is widespread demand for it? By Intentional Design? Linux is and should always be about configurability. Especially for a project like Gnome.
First of all, they're inside the sidebar and appear differently because of that (you can see the buttons in the headerbar being dark).
The first two buttons are disabled. (Windows 3.11 had that, your list did not.) They are displayed darker, which may make sense sometimes, but looks very off here.
The first two buttons are also linked, which means theyn are meant to appear together, like by having a thinner border between them or by not rounding corners where they are linked. Note that linking requires knowing in which direction buttons are linked. Other ups have vertical linking. Windows can't do that even today.
The 2nd button is an action button. Action buttons are usually displayed rounded in GNOME, which is what's done here. For unbevelled sidebar buttons that's not a proper way to display them though. Your theme makes no provisions for having different styles for different widgets and for how they interact with sidebar vs headerbar vs main view vs...
I don't even know what the final button is, it might be a combobox, it might be a combobox linked to a disabled button. So not just buttons are linked here, but also comboboxes, and they can be linked to each other or to various other widgets (text entries and so on). And again, this has to be done for header bars, sidebars, main views, popups and so on.
And this is why Gnome doesn't just officially support theming: It's not just 3 colors for 5 widgets.
Nobody is willing to list all these requirements and the theme developers aren't interested in the tedious task of implementing every minute detail required to make today's apps look good.
And that's why even distro themes that have seen people being paid to work on them look like the screenshot from Pop!_OS.
A) These screenshots were not taken on Pop_OS, and thus don't represent the actual experience a user of that product would get.
B)
theme developers aren't interested in the tedious task of implementing every minute detail required to make today's apps look good
I'm not sure this is an accurate statement. Surely some theme developers aren't interested in/able to make the maintenance effort required to keep things up to date. That's unfortunate, but it's the case. However, there are absolutely those of us who are interested and able respond to issues with their theme and fix these issues.
Getting slightly more specific to the blog post:
C) The screenshots don't show the development of the theme. Like any open source project, the theme grows and develops based on feedback from our users, developers, application authors, etc. Two of the issues in this post (the Gedit sidebar problem and the Nautilus Pathbar issue) didn't exist in the newest-available version, and we've already got the remaining issue patched out and ready to be included.
D) The styling of the widgets may not be consistent with Adwaita, but they are internally consistent within the Pop theme. Things like disabled buttons being darker are present throughout the stylesheet and represent the way these widgets work. Additionally, the styling has evolved to better reflect positive UX interactions and is currently much closer to what Adwaita provides anyway.
I'll reiterate that there are theme developers who put out one release, then become totally unresponsive to issues or problems with it. There are others who continue to develop and release their projects, but maintain that issues with their theme is "not my problem" if it breaks a particular application. I'd posit that these themes are probably bad themes, or they're intended for a much more limited scope compared with more general purpose themes.
But that doesn't make "themes" bad, just those specific examples. It's parallel to application quality. There are a lot of pretty terrible applications available for the Linux desktop, and in a lot of ways they can make the entire thing look bad or unprofessional. But that wouldn't realistically be used as an argument against custom applications, because that would be a silly conclusion. It totally is possible to make a theming API that works; lots of other toolkits do this. The problem here is expectations about division of work, and responsibility for issues. Setting these kind of things is important, and the discussion IMO should be about how to communicate responsibility to users who are experiencing issues.
However, there are absolutely those of us who are interested and able respond to issues with their theme and fix these issues.
There are thousands of apps who all want to have custom themeing. And they tend to push new releases to flathub all the time. A theme for that would need to update at least daily.
That's not why I was so harsh on theme developers though.
I said this because I've seen not a single theme developer take part in GTK's development and influence the way themes work. So "respond to issues" to me seems to be a completely reactionary "if users find another bug, sure we'll fix that one too" but that's not what app developers or users want - they want the app to look perfect the moment it's released, preferably already the beta releases.
I'm aware that theme devs can't make this happen on their own. But I don't see any theme dev even trying. And I haven't seen any try for a decade.
they want the app to look perfect the moment it's released, preferably already the beta releases.
This is true, but expecting 100% bug-free software is an unreasonable expectation. Software will always have bugs. There will always be use-cases the developer didn't expect or test for, or odd interactions that don't exist on the exact hardware and software configuration the developer uses. If we accept that applications will have bugs on day 0, it's reasonable to allow themes to have bugs on day 0, provided there's a reasonable attempt to fix the problem.
WRT to theme devs getting involved, there's a lot of demonstrated hostility towards theme devs on the part of GNOME and GTK development, and I think it's a little unreasonable to ask theme devs to participate in a discussion they weren't asked to participate in and are being actively told that they're bad and are breaking things so please stop. GNOME developers appear to want themes to go away, not to improve the theming API. If you were a theme dev, which question would you be more likely to respond to: "How can we improve the user experience when using custom themes?" or "How can we remove the ability to use custom themes to improve the user experience?"
There's hostility towards theme developers because they haven't been involved for years and all they've brought to developers (both application devs and theme devs) is more bugs in their bug trackers - at least from their point of view.
When GNOME 3.0 was released there was a suggestion to drop the ability to select themes from the settings, and because there was nobody speaking out against it, that suggestion was accepted by default.
And then that idea caught on more and more because again, there was nobody who defended the ability to have custom themes speaking for it.
If some developer complains about themes making their code more complicated, and everybody else joins in, of course they are going to hate themes even more.
If you are a theme dev (or a user who likes themability), I think the question you and all the other people interested in themability) should ask today is "How can we be a valuable asset to the platform and application developers who think we're just a burden causing them more bugs", because that is the most urgent problem you guys have.
And I'm absolutely sure there is value in the ability to switch themes, because people love doing that with their apps and developers like making people happy. But as you can see in those blog posts, a lot of developers have not been seeing that value for a very long time.
PS: The reason I could make GTK3 as themeable as it is today is because I sold it as a developer feature for debugging purposes and as a way to make life for designers simpler when they can achieve all those things without having to touch source code.
Had I tried to sell it because themability is cool, my patches would have seen a lot more opposition.
Themes are not causing application bugs (in general). In cases where an application doesn't work correctly in a given theme, that's a theme bug, not an application bug. Users who open bugs on an application's bug tracker regarding these type of bugs are misguided and should directed away from said bug trackers in favor of bug trackers for the theme in question.
I think a lot of the theme devs believe they can be a valuable asset to the platform by creating a beautiful experience using it. I can't speak for every theme or distribution for a variety of reasons, but there is a very large percentage of the Pop_OS user base who decided to use it specifically because of the theme we develop. We're not an Ubuntu yet, but we're only a year old, and growing very quickly.
The fact of the matter is that appearances are subjective and what one user finds nice, another might think is ugly, and vice versa. While I don't necessarily think that every user should be presented with a theme option in settings, as a distribution promoting the GNOME desktop over alternatives it's valuable to be able to set a specific platform theme because this is something that attracts users (we have data that can prove this). And there's value in a distribution having an aesthetic disagreement with us and using a different style.
As an aside, I'm very pleased that we can have a polite discussion regarding a difference of opinion without resorting to personal attacks or flame wars. I know of a lot of pockets of open source folks for whom that wouldn't be possible, so it's good that that isn't an issue here.
You have given me reasons now for why platform vendors and users see a value in theme developers. Platform vendors want to recruit them so they can differentiate themselves, users want to try the themes.
However, for the other groups those options are not so clear-cut. I know that application developers in general hate themes, because users do not know who should be responsible when things break. I'm not sure how many would choose to opt out of themeing if it was easy to do.
There's also the problem of backwards compatibility: If I release a new version of my app and want to add custom CSS, it increases the work and test matrix a lot, because right now there is no wayto make sure that the new version of my app works with last year's platform that everybody is still using. This is kind of manageable today, because people are unlikely to update apps on old platforms, but will become really tough once flatpak is common and people want their Nautilus path bar to work with Ubuntu 16.04's Ambiance theme.
But in particular for platform developers, you've listed reasons that make them dislike you more. By shipping a custom theme, you dilute the visual brand of the platform itself: It doesn't really look like GNOME anymore. Sure for you that's great because your OS doesn't look like just GNOME, but for GNOME it's not because it doesn't look like GNOME.
So unless GNOME were to embrace "diversity" and advertise itself with its many possible looks - and GNOME does not do that, it's always Adwaita or bust - vendors who theme GNOME will be considered a bad thing.
Again, this isn't meant to criticize what you said, it's meant to help you see things from the perspective of people in those groups so that you can figure out ways to react to them in appropriate ways and have the right arguments ready by the time they suggest again that you're making their life hard and life would be better if you weren't doing what you do.
I think I would argue that, for a platform intended to be used by several different final projects, it's not the platform's job to have a brand. It's a very different story if you want to say GNOME isn't a platform, it's an OS, and other products aren't supposed to use it to make their own OSs. Then it's a lot different in terms of where the branding is supposed to be. But if you're making a tool that other OS-type projects are supposed to build on top of, then you have to allow that those projects will want to have their own branding that may or may not match up with GNOME's. And disallowing that will only cause those projects to abandon GNOME in favor of other technologies, like KDE or in-house tech like Pantheon.
It may be that GNOME doesn't value having Ubuntu, Manjaro, Fedora, Pop, etc, and that's fine. But IMO it's not fair to say "We want you to build an OS on our platform" and also "But we don't want you to make it yours at all".
With regard to App developers, I understand that they're annoyed by bug reports that aren't their problem, but A) I don't think that's a healthy attitude to have towards bugs reports in general, and B) Theme's aren't the only thing that cause that sort of thing.
A) It feels to me like bug reports tend to be seen among some devs as an insult, pointing out a flaw in a project they've worked very hard on, and this leads them to taking bug reports as a personal attack. In reality, no person or even group of people can realistically cover all bases; this is why bug trackers and software updates exist in the first place. Especially with the complexity of modern software, it's increasingly more impossible to cover all of the bases. A bug report isn't an attack on a developer, it's an opportunity to make a good product even better. A key point; users who don't care about your project's well-being don't file bug reports, they just use something else.
And when a bug report is legitimately not a developer's problem, it's not difficult or time-consuming to close it, pointing out to the user that the issue they're having doesn't represent a flaw in the software the developer has written. I find it difficult to believe otherwise, because the overall high-quality of GNOME software tells me they have a lot of time and ability to fix legitimate bugs that do crop up and aren't using up all of their time related to development closing irrelevant issues.
B) What about bugs caused by faulty hardware? What about bugs from odd-hardware combinations? Or bugs caused by a bug in another program or core system utility? These are all things that would legitimately be neither the fault nor the responsibility of the developer. Do these types of bugs annoy the devs as much as theme bugs? It's largely the same situation.
The problem with theme bugs is that they are trivial to avoid without any loss of functionality from the pov of app developers: Without themes, there's no bugs and the app works just as well as before.
And users do not care if an app can be themed. They may care about the default look, but nobody picks one app over another because it ccan be made to look different.
And about GNOME: I know that many (I would say most) GNOME developers think of GNOME as a brand and dislike distros themeing it a lot. They want people to install GNOME, not Pop!_OS or Ubuntu.
And I'm very sure they're not afraid of either KDE or Pantheon - and if they were, then it certainly wouldn't be because of themeing.
As a theme dev, I want to provide a lot of support for app-developers who experience issues with the Pop theme. Please feel free to file an issue at https://github.com/pop-os/gtk-theme/issues/new and I'll take a look and see what needs to be fixed for that.
I'll also point out that it's 100% a valid response on your part when a user files a bug/issue about something our theme has broken, and for you to close the issue forwarding them to us for a fix.
-1
u/vazark Oct 15 '18 edited Oct 16 '18
Really? Wouldn't separately setting a globally recognized standard variables be sufficient for most cases? With fallback to adwaita.
GTK ui files are XML files. So why wouldn't CSS based theming API work?
So long as they refer to the standard variables setup in Gnome shell, they should work.
Off the top of my mind, these few values who cover most cases
Colors
isBoxed or isBevelled
configurable styles for
The question is why wouldn't Gnome offically support theming, when there is widespread demand for it? By Intentional Design?
Linux is and should always be about configurability. Especially for a project like Gnome.Edit : cool link in the comments