Moving Beyond Themes

Over the years FreeDesktop platforms have come a long way in terms of usability and as we strive to make them better platforms for application developers, I think it’s time to shed one more shackle that slows that down: themes.

Now, coming from me that view may be a surprise (because of all those themes that I call personal projects) but I do feel it’s necessary mainly because the level of visual customisation that is being done at the distribution level has led to widespread visual fragmentation which impacts both user- and developer-friendliness.

Letting the Past Go

What themes used to be were sets of preset or configuration files that would only tweak the details of the user interface such as the window borders or how buttons and scrollbars looked but the overall layout and function stayed the same.

But user interfaces of the past were much simpler, there were fewer window states, fewer points of interaction, less visual feedback, and just plain fewer pixels. These limitations in old toolkits meant that they largely stayed the same from theme to theme and things were relatively stable.

Fast-forward to today where we have modern toolkits like GTK+ 3 with more complex visuals and detailed interactions means that without the same level of quality control that you find at the toolkit level, maintaining a separate theme is a very fiddly and potentially buggy prospect. Not to mention getting all the details right matters for both usability and accessibility.

“Look and Feel” as a Toolkit Component

It’s unfortunate that “Adwaita” is thought of as a theme when in fact it is a core component of the toolkit, but this is mostly a holdover from how we’re used to thinking about look and feel as it relates to the user interface. Adwaita is as closely tied to GTK+ as Aqua is to the macOS user interface, and as a result it has broad implications applications built with GTK+.

The reality is that GTK+ 3 has no theme framework (there is no API or documentation for “themes”) and “Adwaita” is simply the name of the stylesheet deeply integrated in GTK+. So when third-party developers build GNOME apps, they rely on this stylesheet when determining the look and feel of their apps and, if necessary, use it as a reference when writing their own custom stylesheets (since it is a core toolkit component).

Today’s themes aren’t themes

GTK+ 3 themes are not themes in the traditional sense. They are not packages of presets designed to work with the user interface toolkit, they are more like custom stylesheets which exist outside of the application-UI framework and only work by essentially overriding the toolkit-level stylesheet (and quite often only the toolkit-level stylesheet).

When GTK+ 3 applications are being used under third-party themes, what is being broken is the boundary an application developer has set up to control both the quality of their application and how it looks and feels and this becomes really problematic when applications have custom CSS.

In order for third party themes to work properly and not cause cascading visual bugs, they have to either become monolithic and start incorporating all the custom stylesheets for all the applications that have them, or work with application developers to include stylesheets in their applications that support their themes. Neither of these solutions are good for platform or application development since it will become a task of never-ending maintenance.

Visual Fragmentation

Across the GNOME desktop ecosystem exists “visual fragmentation” and it’s a very real problem for app developers. Since very few distributions ship GNOME as-is, it is hard to determine what the visual identity of GNOME is and therefore it’s difficult to know which visual system to build your application for.

Integrating the stylesheet with the user interface toolkit, in theory, should have solved many issues regarding visual inconsistency across the GNOME platform, but that’s an unsolveable problem so long as themes persist.

The biggest offenders continue to be downstream projects that theme GNOME extensively by overriding the default icons and stylesheet, and insist that that’s part of their own brand identity, but so long as that practice carries on then this fragmentation will continue.

Upstream vs. Downstream Identity

It is extremely rare for a Linux distribution to also be the platform vendor, so it can be said that nearly all distros that ship a desktop platform (like GNOME) are “downstream” vendors.

Platforms like GNOME and KDE exist irrespective of distributions and they have their own visual and brand identities, and own guidelines around the user interface. On the other hand, distribution vendors see a need to have unique identities and some decide to extend that to the look and feel of the desktop and apply themes.

But this practice raises questions about whether it is right or not for distributions to cut out or override the upstream platform vendor’s identity to favour their own. Should distributions that ship GNOME be asked to leave the default look and feel and experience intact? I think yes.

A similar situation exists on Android where Google is trying to control the look and feel of Android and hardware OEMs all over the place are skinning it for their phones, but the blame for issues gets conflated with issues in Android (unless you do some monumental branding effort and effectively erase Android, like Samsung)

Distributions owe a lot to the desktop platforms, as such I think that effort should be made to respect the platform’s intended experience. Not to mention, the same concerns for quality assurance regarding applications also applies to the platform, GNOME developers lose out when then forced to dedicate time and resources to dealing with bugs related to issues created by downstream theming and deviations.

The Future

If ending the wild west of visual customisation (which would probably end all of those projects of mine) on GNOME is necessary to grow the ecosystem, so be it.

I would rather see GNOME evolve as a platform and become a little less developer-hostile by dropping support for third-party themes, than stagnate. Doing so would also bring us in line with the how the major (successful) platforms maintain a consistent look and feel and consider app developers’ control over their apps and their rights to their brand identities.

That said, I doubt such a hardline position will be widely warmly recieved, but I would like to see a more closed approach to look and feel. Though, perhaps actually building some sort of framework that allows for custom stylesheets (so that downstreams can have their unique visual identities) that doesn’t involve totally overriding the one at the toolkit level would be the best solution.