Theming & Ecosystem BoF
See the hacking/BoF days page for time and location information.
Subject
Downstreams shipping different GTK and icon themes are making our platform very hard to target for third-party developers. It's also a problem because we end up with a lot of apps' styling breaking in subtle ways that are impossible to debug at scale. This is bad for users because it results in a bad experience, bad for distros because it's a never-ending source of bugs, and generally makes free software look bad. We want to improve this situation and provide a predictable platform people can build on, while addressing the concerns that downstreams have with the upstream default themes.
On the icon side we also want to decentralize symbolic icons, in order to be able to provide a larger library of icons to developers, in a way which doesn't require maintaining them forever.
Audience
- Distros/downstreams (both ones shipping themes, and ones who aren't)
- Adwaita maintainers
- App developers
Organizers
Participants
People who are planning on or are expected to attend:
Cassidy's Notes
"Right now we don't have a clear development target for the GNOME platform."
"What I want to do today is—I don't want to push any solutions, but I want to talk about the problems."
- User: wants lots of non-broken apps
- Users of OSes pick them in part because of this modification and changes experience
- Developer: want stable platform
- Distributors: want branded, unique, and consistent experience
"The driving force for Flatpak was that it's predictable: I make and app, and I know the parts of it are not going to be changing so I can deliver to users and QA."
"Right now it's kind of okay because we have dozens of apps. As the ecosystem scales to thousands of apps, it becomes unscalable."
"Lots of different groups: upstream unmodified GNOME, modified GNOME-based distribution, GNOME-based platform (where apps are built for the platform), OSes like elementary OS where it's GNOME-based technologies like Gtk+"
"User vs Distro: user side basically the same, where they can do it if they really want, and keep the pieces."
Four aspects: GTK Themes, Icon Platform, App Branding, GNOME Visual Refresh
GTK Themes
GNOME Shell is a bit different, as the platform controls that and app developers are not writing "Shell Apps"
"One of the things I'd like to put out there is: is there any way we can come together and work together on the upstream (Adwaita) theme?"
Developing a more API'd Adwaita
Possibilities:
- make apps better across themes
- structure themes that ensure compatibility
- allow apps to whitelist themes they're compatible with (Adwaita as a fallback)
With GNOME Calendar, if you really customize the CSS for it in the theme, it's loaded when every app is opened (like 2.3 MB CSS).
Proposal: A GNOME/Adwaita Styling API: distros target this API, and get consistency in apps that are designed for GNOME. Up to app developers to adopt this API. Everyone is interested in moving forward on this potential future for GNOME platform downstreams (i.e. Ubuntu and Pop!_OS). Have to get into a room/chat and look at what we change, what sort of an API (if any) would be acceptable to us all. But in the room it sounded like we all wanted to see this move forward. Georges mentioned organizing a cross-desktop discussion for Pop!, GNOME, Ubuntu, etc. people.
Icon Platform
Really different problems:
- Technical implementation of how icons work (works well now with GResource, fallbacks, etc.).
- Standard, large set of icons/assets: some how community driven with tags and references that devs GResource into their app for things outside of whatever the spec is.
- Adwaita is big and unmaintainable: what icons should be shipped in Adwaita? Should it be shipped at all?
- The core icon spec is outdated.
The consensus seemed to be that this was more of a tooling and developer documentation issue; all the existing technologies are pretty good, but we might need to work with app developers on educating them of best practices, plus some sort of GNOME collection of assets that developers can GResource into their app as a fallback could be nice (points 1 and 2). As a part of that, Adwaita should probably be pared back to the essential icons, or perhaps just cover the FD.o spec (point 3). At the same time, Daniel from elementary and Jakub should probably get together to go over the spec and see what proposals could be made to modernize it and include really commonly expected semantic icons (point 4).
App Branding
Didn't spend a ton of time discussing (we were running short on time), but the consensus seemed to be that with a more stable API and style consts in Adwaita, it could open up app developers to be able to do more interesting branding while staying interoperable with "Adwaita-compatible" themes.
GNOME Visual Refresh
We talked about the existing GNOME icon style (3D rendered, hyper realistic, etc.) and the problems with third-party apps (high barrier to entry, a lot more work for a render plus several hinted sizes). The proposed way forward is an icon style refresh that uses a consistent grid, a bit flatter style, and a refreshed palette. Designed for 64px (exported at higher sizes), but aligned colors on a grid means downsizing should be doable without having to re-hint.
elementary wants to make sure there aren't toolkit-level changes for icon hinting as they heavily use hinting for their icons, but this sounds sane for GNOME's first- and third-party app ecosystem. The style was pretty reminiscent of Pop!_OS's material-inspired icons, so we could see a future where Pop! themes first-party/default apps, but then doesn't need to theme any third-party apps while still retaining visual consistency. Good stuff.
Blog Posts
Blog posts about the session:
- ...
- ...
- ...
