Re: Theme Expandability (was Re: Plans for 1.3/1.4)

[Pavel Machek <pavel atrey karlin mff cuni cz>]

Hi!

> > I took a look, looks nicely. My idea would be:
> > 
> > gtk+ allocates GtkStyleClass, and fills in all fields to default
> > behaviour. Theme overwrites some of them with functions/values it
> > wants to supply.
> 
> I'm not sure I understand.  Aren't themes creating the whole
> GtkStyleClass already?  I so, I can't see how this new aproach can
> give you more freedom than the existing one.

And there's a problem: if I add a field to GtkStyleClass, everything
will break because existing (we are talking about binary compatibility
here) themes will alloc smaller array.

OTOH, if you let core alloc GtkStyleClass, and initialize it with
defaults nothing will break: theme just will be unable to touch fields
it knows nothing about.

> > PS: Notice that in my patch I added new GdkStyleExpand field - that
> > was in order not to break binary compatibility with existing
> > themes. Above approach is cleaner but breaks binary compatibility.
> 
> First of all, is your patch available somewhere?  I've been having
> problems (hopefully solved now) with gtk-devel-list, so if you posted
> it to the list I may have missed it.
> 
> On the other hand, looking at things more carefully, I just realized
> that moving the new [xy]thickness fields to the end of the GtkStyle
> structure, and keeping the old fields in GtkStyleClass would resolve
> most of the binary (and source) incopatibility problems in my
> solution.  I'll try to do that (as well as updating my patch for the

Yes. That is second possibility.

								Pavel

-- 
The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+