GUADEC Theming API meeting minutes

[Alberto Ruiz-4]

Hi all,

this is a summary of the issues discussed and the roadmap about a new
theming API for Gtk+ at GUADEC:

Current situation:
------------------------

Misc:
  * Engines are too dependent on widget implementation details
  * Proper color inheritance for widgets (use case: slider text on
dark themes is white instead of black)
  * Color naming is highly confusing
  * Style can't be easily updated depending on different values of
properties (invisible notebook background, possible merge of scrollbar
and h/vbox widget)
  * Hard for artists to create themes right without writing an engine
  * Widgets are not transparent by default
  * The detail string is too static and once you choose one detail you
can't change it without breaking the engines

OS Integration:
  * Dynamic gtkrc properties not supported and, right now we parse
snippets on code and those strings are not updated if the engine is
changed which makes the current code quite hard to read and maintain.

Roadmap:
  * Create a CSS engine to play with it and see how far can we go with
flexibility in the artist side (Andreas to make mockups of the new
syntax and figure out how to implement it afterwards)
  * Consistency for style properties naming and using (Andreas)
  * Define what the new API should look like and see if we can come up
with something for 3.x (Benjamin and Alberto will look into this)
  * GSEAL GtkStyle members
  * Add API for dynamic rc style properties (Benjamin)
  * Define a new set of names for style colours (Andreas to select a
better naming for artists?)
  * Look at drawing widgets transparently by default and provide an
API to get the alpha mask for look and feel integration (mozilla,
swing, Qt) (Garnacho??)
  * We need a new GtkStyle object for 3.x (Benjamin and Alberto)

--
Cheers,
Alberto Ruiz
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Paul Davis]

On Mon, 2008-07-14 at 16:42 +0100, Alberto Ruiz wrote:
> Hi all,
>
> this is a summary of the issues discussed and the roadmap about a new
> theming API for Gtk+ at GUADEC:

great set of notes and maybe even goals. i'd love to see another issue
incorporated that is closely related to, though not identical to, some
of the ones raised. see http://bugzilla.gnome.org/show_bug.cgi?id=407215
for details ("the PRELIGHT state is misdesigned and unusable with
colored widgets").

--p




_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Benjamin Berg]

On Mon, 2008-07-14 at 11:49 -0400, Paul Davis wrote:

> On Mon, 2008-07-14 at 16:42 +0100, Alberto Ruiz wrote:
> > Hi all,
> >
> > this is a summary of the issues discussed and the roadmap about a new
> > theming API for Gtk+ at GUADEC:
>
> great set of notes and maybe even goals. i'd love to see another issue
> incorporated that is closely related to, though not identical to, some
> of the ones raised. see http://bugzilla.gnome.org/show_bug.cgi?id=407215
> for details ("the PRELIGHT state is misdesigned and unusable with
> colored widgets").

Thanks for the note. I had not thought of that issue before.

Would everyone be fine if I start adding a "theme" keyword to any bug
that is about theming or will affect themes?
It may also be a good idea to create a tracker bug for issues that can
be addressed with an API change like this.

Benjamin


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Cody Russell-2]

On Mon, 2008-07-14 at 15:56 +0000, Benjamin Berg wrote:
>
> Would everyone be fine if I start adding a "theme" keyword to any bug
> that is about theming or will affect themes?
> It may also be a good idea to create a tracker bug for issues that can
> be addressed with an API change like this.

Yeah, and it would be great if someone would get all this information up
on l.g.o as well. :)

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Morten Welinder-2]

You had such a meeting and no-one wanted to address the sad fact
that theme engines in their current form are a major source of mysterius
bugs when they corrupt the state of the running program.

Morten
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Benjamin Berg]

On Mon, 2008-07-14 at 11:04 -0500, Cody Russell wrote:
> On Mon, 2008-07-14 at 15:56 +0000, Benjamin Berg wrote:
> >
> > Would everyone be fine if I start adding a "theme" keyword to any bug
> > that is about theming or will affect themes?
> > It may also be a good idea to create a tracker bug for issues that can
> > be addressed with an API change like this.
>
> Yeah, and it would be great if someone would get all this information up
> on l.g.o as well. :)

Well, currently it is unfortunately a bit of a mess (but most
information is there). There is
http://live.gnome.org/GTK%2B/NewThemeApi/Roadmap and several pages
underneath it. I have created a Roadmap page at
http://live.gnome.org/GTK%2B/NewThemeApi/Roadmap .

Benjamin


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Benjamin Berg]

On Mon, 2008-07-14 at 12:06 -0400, Morten Welinder wrote:
> You had such a meeting and no-one wanted to address the sad fact
> that theme engines in their current form are a major source of mysterius
> bugs when they corrupt the state of the running program.

This is a problem, but it cannot be addressed by taking engines out of
the equation. We need engines at least for OS integration, so I think
that the best thing we can do is to create a proper quality assurance
for them. A big step would be if we have one good engine on the GNOME
desktop that handles almost all themes, as there will not be as many
third party engines then.

Also I would like to point you to the fact that the quality of the
engines has improved dramatically. At least all engines that are part of
gtk-engines do get proper testing. (In the past I have literally removed
hundreds of places where NULL pointers would be dereferenced and other
bad things could happen.)
I do not know whether the ms-windows or OSX engines are tested in a
similar way, but it would probably be a good thing (I could help setting
things up if wanted).

Benjamin


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Cody Russell-2]

On Mon, 2008-07-14 at 12:06 -0400, Morten Welinder wrote:
> You had such a meeting and no-one wanted to address the sad fact
> that theme engines in their current form are a major source of
> mysterius
> bugs when they corrupt the state of the running program.

But I think that's a result of having an inflexible theming system.
Ideally we want everyone to theme GTK without having to write custom
code, and reserve custom code engines for things like Win32 theme engine
and such.

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Owen Taylor]

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


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[CODY RUSSELL]

On Mon, 2008-07-14 at 18:25 +0200, Benjamin Berg wrote:
> This is a problem, but it cannot be addressed by taking engines out of
> the equation. We need engines at least for OS integration, so I think
> that the best thing we can do is to create a proper quality assurance
> for them.

And the OS integration engines are also more likely to have people who
will be responsible for fixing the bugs.  The Win32 engine right now has
me, Dom, and Alberto fixing things.

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Hagen Schink]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,

I used the last two weeks to think about a new/other way to integrate theming into GTK+. The main concern I took into account was the following one:

>   * Hard for artists to create themes right without writing an engine

Because artists have there favourite tools I decided to take SVG as basic assumption. The main advantage is that a lot of great graphics editors are out there that can create SVG files. Furthermore it's easier to apply a CSS like layout system on it because there are XML elements with ids, classes and attributes.

With this approach it should be easier to get the following things working:

> Roadmap:
>  * Create a CSS engine to play with it and see how far can we go with
>flexibility in the artist side (Andreas to make mockups of the new
>syntax and figure out how to implement it afterwards)
>  * Consistency for style properties naming and using (Andreas)

At the end the only thing that the theming engine should do is to call drawing functions that match the specific SVG element.

At the moment I think of the some performance issues concerning the usage of SVG. I have a possible solution but I am also waiting for some advice on it.

I hope this idea can help you to find a good solution for theming in GTK+. If not please don't rip of my head because I'm new to the development of GTK+. :-)

Kind regards,
   Hagen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkh7hqMACgkQ1UAqryBcuEU4HACfe7s1KHD7emctqUN6+Wj7CFmY
VvkAnAggslqGnPTWVBE94FqPHT1+75C1
=fNKK
-----END PGP SIGNATURE-----
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Thorsten Wilms]

On Mon, 2008-07-14 at 16:42 +0100, Alberto Ruiz wrote:
> Hi all,
>
> this is a summary of the issues discussed and the roadmap about a new
> theming API for Gtk+ at GUADEC:
>

> Roadmap:
>   * Create a CSS engine to play with it and see how far can we go with
> flexibility in the artist side (Andreas to make mockups of the new
> syntax and figure out how to implement it afterwards)

I hope this will include being able to specify sizes/spacing relative to
font height and x-height, em and ex?

Oh, and spacing between widgets shouldn't be a fixed part of layout. It
should all be defined in themes. No more studying the HIG and manual
labour to get that right. 100% consistency and flexibility instead.

--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Alberto Ruiz-4]

2008/7/14 Thorsten Wilms <t_w_@...>:

> On Mon, 2008-07-14 at 16:42 +0100, Alberto Ruiz wrote:
>> Hi all,
>>
>> this is a summary of the issues discussed and the roadmap about a new
>> theming API for Gtk+ at GUADEC:
>>
>
>> Roadmap:
>>   * Create a CSS engine to play with it and see how far can we go with
>> flexibility in the artist side (Andreas to make mockups of the new
>> syntax and figure out how to implement it afterwards)
>
> I hope this will include being able to specify sizes/spacing relative to
> font height and x-height, em and ex?

Don't hope, just help us to write the code :) There's nothing working
yet, just plans.

>
> Oh, and spacing between widgets shouldn't be a fixed part of layout. It
> should all be defined in themes. No more studying the HIG and manual
> labour to get that right. 100% consistency and flexibility instead.

That works belongs to Glade/GtkBuilder, themes define style not
layout. Having HIG values by default on dialogs, buttonboxes et al is
another discussion.

--
Un saludo,
Alberto Ruiz
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Tuomas Kuosmanen-3]

2008/7/15 Alberto Ruiz <aruiz@...>:

> Oh, and spacing between widgets shouldn't be a fixed part of layout. It
> should all be defined in themes. No more studying the HIG and manual
> labour to get that right. 100% consistency and flexibility instead.

That works belongs to Glade/GtkBuilder, themes define style not
layout. Having HIG values by default on dialogs, buttonboxes et al is
another discussion.

Themes could well define layout styling (spacing etc) while the basic layout (table, hbox, whatever) is defined by something else.

Layout: "table with 2 columns, 4 rows and a horizontal list of buttons below it"
Style: "Widget spacing is NN units, colour is ZZ and font used is XX, buttons have this kind of look..."

If you think of this as an analogy to the web, CSS *is* used to define "spacing" and all that.

- T, back to vacation mode =)

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Robert Staudinger]

On Mon, Jul 14, 2008 at 5:42 PM, Alberto Ruiz <aruiz@...> wrote:

> Hi all,
>
> this is a summary of the issues discussed and the roadmap about a new
> theming API for Gtk+ at GUADEC:
>
> Current situation:
> ------------------------
>
> Misc:
>  * Engines are too dependent on widget implementation details
>  * Proper color inheritance for widgets (use case: slider text on
> dark themes is white instead of black)
>  * Color naming is highly confusing
>  * Style can't be easily updated depending on different values of
> properties (invisible notebook background, possible merge of scrollbar
> and h/vbox widget)
>  * Hard for artists to create themes right without writing an engine
>  * Widgets are not transparent by default
>  * The detail string is too static and once you choose one detail you
> can't change it without breaking the engines
>
> OS Integration:
>  * Dynamic gtkrc properties not supported and, right now we parse
> snippets on code and those strings are not updated if the engine is
> changed which makes the current code quite hard to read and maintain.
>
> Roadmap:
>  * Create a CSS engine to play with it and see how far can we go with
> flexibility in the artist side (Andreas to make mockups of the new
> syntax and figure out how to implement it afterwards)

Thanks for the heads up. To avoid duplication of efforts, I am working
on such a theme engine for some time and have been discussing issues
with Benjamin, Andreas, Jakub and others.

Code: http://bzr-playground.gnome.org/~robsta/gtk-css-engine/
Screenshot: http://www.gnome.org/~robsta/gtk-css-engine/01-first-roundtrip.png

I think gnome-themes-list is an appropriate place to discuss it, if
anyone's interested in details and/or plans.

What exactly is meant by "mockups of the new syntax" by the way? I'm
planning to use a strict CSS subset.

Best,
Rob
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Hagen Schink]

Hi,

ok, I didn't get any response to my theming proposal. So please have look on this:

http://techbase.kde.org/Development/Tutorials/Plasma/Theme
http://techbase.kde.org/Projects/Plasma/Theme#Theme_Storage

It's similar to what I proposed for GTK+ in my last mail. I don't know how they implement that but I will have a look on this within the next days. But I guess by building on the efforts of librsvg and implementing a very good caching strategy GTK+ theming could also benefit from this approach.

There must be some imendio developers who have my detailed and really "academic" ( ;-) ) proposal with a nice draft :-D.

Kind regards,
   Hagen
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list