Re: GUADEC Theming API meeting minutes

[Owen Taylor <otaylor redhat com>]

Sorry to miss the theming meeting ... I tried to make it, but was
unable to ocate it.

Some quick notes on theming:

- We can't escape the reality that people want to use GTK+ theming
  without GTK+ widgets. The hackaround that Openoffice, Firefox,
  and Java do to do this currently are horrifying... they create
  dummy widgets that are offscreen then munge them to match what
  they are trying to draw at the moment.

  This makes me think that the right thing to do is to create a 
  theme system that is independent of GTK+ widgets; probably 
  in a theme library that is independent of GTK+.

  Then you could for compatibility create a theme engine for 
  GTK+ that bridges to the new library, using all the standard
  reverse-engineering tricks that the current theme engines
  do. Core GTK+ widgets could be rewritten to use the theme 
  library directly leaving old custom widgets using the 
  bridge theme engine. GtkStyle could be deprecated and removed.

- The intersection of 

   A) Custom theming
   B) Custom widgets

  Is really, really hard. I've been thinking about it off and on
  for several years, and never came to a satisfactory solution.

  Handling this combination was what we were aiming at for with
  GtkStyle ... the idea was that if the "parts" were drawn in a
  default fashion, then you would get something acceptable,
  but you could look at the detail strings and get a better match.l

  This, in my opinion, didn't work out. People tend to skip 
  using GtkStyle altogether for custom widgets and maybe use some
  color from the theme. Or what they want is to draw pretty much
  like some existing widgets, and have to read the code to figure
  out the detail strings.

  So, at this point, my opinion is that the theme library referenced
  above should just be designed to draw a (possibly large) set
  of standard widget types.

- The theme library should be primarily be considered to be
  *the* Linux Native Theme API ... if bridging to other theme APIs
  is desirable, it should be a secondary thing and shouldn't drive
  the design.

  For native themes, I think you want to concentrate on declarative
  theming, or if that is entirely insufficient, maybe consider using.
  a scripting language.

- Owen