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)

GUADEC/2019/Hackingdays/VendorThemes/Notes (last edited 2019-09-03 17:28:48 by TobiasBernard)