Useful resources: https://wiki.gnome.org/Design/OS/DownstreamBranding

• Developers want to test against one theme
• Identify common breaks
• Custom widgets tend to be an issue (custom implementations)
• When an app uses a widget
• Issues testing themes
• Want to get a roadmap
• Upstream theme
• How do you test against many themes? (This can't be done)
• Can you rely on the basic exported colours (foreground/background/highlight etc)
• However, some apps use hard-coded colours, causes issues for people who desire to theme
• Perhaps a theme deliberately breaking broken apps? GTK Warnings if one color (fg/bg) in a, say, button comes from application that didn't look up theme colors, and the other from theme CSS?
• Officially supported is Adwaita - how do we do QA?
• Not great toolkit support for some of the patterns - different implementations of listbox
• Even if there's a list of things we can perscribe, we can't say "don't do X, as app developers want to innovate/experiement"
• Would be good to work out a better way to test themes, and test apps
• Padding (hard coded) breaks everything in subtle and unusual ways
• Also affects a11y - major issue - High contrast is an issue, Large Text too
• The only way to change all the apps is to "change everything" rather than selective changes
• Showing the fedora logo - distro logo in the top left (though it isn't great, because of window-only screenshots)
• Colour changes can get you 80% if the way there, but it's not /quite/ enough
• Exported colours - can those be relied upon - probably. Custom colours are an issue within apps.
• How much do distros want to change? Is it just accent colours?
• Themes are going to happen, saying that they're not isn't going to help
• Expecting GNOME to test all themes and prevent breakage across all themes also isn't going to be feasible
• Two audiences
• vendors (and non-GNOME desktops) who want to theme where GNOME needs to be clear what can be supported
• app developers who need to be informed what they should use to enable a good theming experience
• Even adwaita changes can cause internal breakage
• Perhaps move to use names of "adwaita3.26" instead of "adwaita" ?
• As an app developer, would be much happier if there was a guarantee that a different theme won't break the app
• GNOME needs to also explain what is supported so the above can be made
• Apps which use custom css are not actually developing in pure Adwaita. It's actually Adwaita-Nautilus (for example)
• Can we provide better tools to apps to enable custom themes?
• How do other platforms do it?
• OS X designs to a particular version (no themes?)
• Android fallbacks to older version (looks bad but works), but also targets a particular version/sdk
• When creating a new theme, vendors also need to ensure that supporting documentation, screenshots etc etc are updated to ensure a good user experience
• How do appstream screenshots work with themes? And also with dark style? ARGAH!

Three categories: Dragons (change these and keep the pieces), Accent Colors/exported variables, Upstreaming

Exported variables:

• General accent colors
• headerbar branding
• color palete variables (non-semantic, like elementary palette)
• dark style
• high contrast
• semantic colors (fg_color, destructive, suggested,

Problems: - trying to align on a set of exported varibles across platforms (not only Adwaita/Pop/Yaru, but elementary) - themes like Arc where there are several variants or fit outside of the expected theme

ACTIONS

• sit down look at Adwaita to see what is no-change exported and documented
• things that should be exported but aren't
• add a color palette/etc.
• social angle: document/blog post
• widget factory type tooling (like Handy Examples or granite-demo)
• Start thread on Discourse to continue the conversation

(Originally from https://etherpad.gnome.org/p/VendorThemes2019/timeslider#1619)