Re: Styles, RC Files, and Themes

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> On 22 Jul 1998, Owen Taylor wrote:

> > 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?

Yes, you need an engine section in the style, because it needs to be
parsed separately by the theme engine, and because we need to specify
the engine that will be used.

Overlaying of engine data:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
style "pixmap-button" {
   bg[NORMAL] = "#aabbcc";
   engine "pixmaps" {
   # This portion parsed by the pixmap theme engine
     bevel[NORMAL][] = { "button.png", 15, 32 18, 3 }
   }
}

style "my-button" {
   engine "pixmaps" {
     bevel[INSENSITIVE][] = { "button3.png", 15, 32 18, 3 }
   }
}
 
class "GtkButton" style "pixmap-button"
class "GtkButton" style "my-button"
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Would basically be left up to the theme engine. 
 
> > 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...

Explode? I'm concerned about it (and thus need to benchmark),
but think it "merely" doubles, not explodes.

Currently we have to (on average) match every widget against
half the patterns. With the change, we have to match every
widget against all patterns.

But, on the other hand, if most patterns are class patterns,
there are some significant improvements that can be made
in our pattern matching.

We could keep the class patterns (or those without wildcards,
though I don't think we really need to support class patterns
without wildcards) in a hash by Type ID. Then we can very
efficiently determine which class patterns are applicable
to a particular widget.

> > 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? ;))

 ftp://ftp.labs.redhat.com/pub/otaylor/styles-patch-2.gz

Regards,
                                        Owen