[Tim Janik <timj@gtk.org>] Re: Styles, RC Files, and Themes

[Owen Taylor <otaylor redhat com>]

------- Start of forwarded message -------
From: Tim Janik <timj@gtk.org>
Message-Id: <199807222309.BAA02339%timj@gtk.org>
Date: Thu, 23 Jul 1998 01:09:42 +0200 (CEST)
To: Owen Taylor <otaylor@redhat.com>
cc: GTK+ Developers <gtk-devel-list@redhat.com>, Gtk+ Devils <gtkdev@gtk.org>
Subject: Re: Styles, RC Files, and Themes

On 22 Jul 1998, Owen Taylor wrote:

> 
> Background
> ==========
> 
> To go along with the work that raster is doing here at
> RHAD on themes, I've been thinking about the subject of
> extending RC files to handle the whims of a theme engine.
> 
> (For those who are unfamiliar with the concept, a theme
> engine is a library of C routines to draw bits of widgets.
> Theme engine + Set of configuration files = Theme)
> 
> 
> My first thought, was simply to do something like
> 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> # Declare a style called "pixmap-button"
> style "pixmap-button" {
>   bg[NORMAL] = "#aabbcc";
>   engine "pixmaps" {
>   # This portion parsed by the pixmap theme engine
>     bevel[NORMAL][] = { "button.png", 15, 32 18, 3 }
>   }
> }
> 
> # Give all widgets in class GtkButton and derived classes
> # the style "pixmap-button"
> class "GtkButton" style "pixmap-button"
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 
> However, Tim pointed out that this doesn't work well if
> a program or user does, on top of the theme:
> 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> style "my-button" {
>   fg[NORMAL] = "ff0000"
> }
> 
> # Set all widgets with the name MyButton to have style "my-button"
> widget "*MyButton" style "my-button"
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Instead of getting a pixmap-button with red text, the
> result is a default GTK+ (non-themed) button with red
> text.
> 
> 
> Both Tim and I had solutions to this problem:
> 
> Tim thought (thinks) that the right thing to do is to
> separate out the theme from the style. 
> style {} declarations would be restricted to exactly
> what they are now, but there would also be style_class {}
> declarations that served two purposes:
> 
>  - They set internal options for the theme engine
>  - They set defaults for the the core parts of the style.
> 
> This is only interesting if different widgets can get
> different defaults, independent of what RC styles are set
> for those widgets. So you have to be able to combine an RC
> style with a certain set of defaults after the fact. If you
> have "n" RC styles and "m" style classes, you can end up
> with n*m different styles.

you should point out that "m" is usually 1. though you are right
that the number of styles may explode if a user makes extensive use
of both, but then again he is probably redefining lots of unneccessary
default values...
i can't make up my mind on this exactly untill i get an idea what all
the various kinds of materials is that will be needed by the theme modules.

> [ 
>   An RC style, is what is declared by a style {} declaration
>   in an RC file. This is different from the actual 'style'
>   object that is accessed as widget->style 
> ]
> 
> 
> Now, it occured to me, if the code is being added anyways
> to allow layering a style on top of a set of defaults,
> you might as well just allow layering one RC style 
> on top of another RC style.
> 
> So, I came up with an alternate approach. Currently, the 
> last pattern specified that matches a widget completely
> determines that widget's style.
> 
> In the new approach, every pattern that matches a widget
> affects the style, but options specified in higher
> priority patterns (those specified later in the file)
> overrides lower priority styles.
> 
> So, the declaration:
> 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> style "my-button" {
>   fg[NORMAL] = "ff0000"
> }
> 
> widget "*.MyButton" style "my-button"
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> simply makes MyButton have the style it would have if the 
> pattern was not there at all, but with a red foreground in 
> the normal state.

do you imply we still have an `engine' section in the style
definition with this?

> 
> Implementation details
> ======================
> 
> I implemented my approach last night, and so far it seems
> to work fairly well. (It needs to be benchmarked some - 
> it should do considerably more pattern matches than the
> current code, since it must match against every pattern,
> not just match patterns until one succeeds, but I don't
> know if this will have a significant effect on 
> performance in the end.)
> 
> The way I did it was to make a GSList of the RC styles for
> every pattern that matched a given widget. Then use the
> GSList as a key to look up the style in a hash table. If no
> style is found, then layer the RC styles together to form a
> style and store that in the hash table.

hm, its not that i baically dislike your approach, but
if we need to match *every* widget against *every* style
upon creation, the creation time for e.g. big menus and
windows that use lots of containers/labels is going to
explode...
currently normal gtk applications only make limited use
of styles in general i expect that to change a *lot* if
themes are actually coming into play.
considering a random set of styles e.g. 10 and a random set
of widgets, i guess that on an average matches appear at about
50% of the lookups. so that for an average widget half of the
styles isn't even attempted to match. that would make up about
5 match attempts per widget. granted, i'm totally guessing here,
and i also have spend some efforts on speeding up the pattern
matches recently. but if themes tend to increase the number of
rc styles significantly, and your approach forces all possible
matches for every widget/rc style combination to be performed,
we are really loosing any chance to get speedy creation behaviour.
after the recent signal and GdkWindow speedups, the pattern matches
are the real bottle-neck on the gtk side.

> 
> Source availability:
> ====================
> 
> A patch against CVS to implement this (no theme support,
> just the modification to the way RC styles are formed
> and looked up)
> 
>  ftp://ftp.labs.redhat.com/pub/otaylor/styles-patch.gz

hrg, i just committed my changes to gtkrc.*. could you be so
kind to upload yet another patch? ;))
/me ducks

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ

------- End of forwarded message -------