Re: Patch: remove hard-coded indicator size (revised)

[Owen Taylor <otaylor redhat com>]

"Daniel Richard G." <straker@fox.mit.edu> writes:

> On 7 Jul 2000, Owen Taylor wrote:
> 
> > Themes are not allowed to modify class variables. Some themes do
> > that, and worse. We tolerate that, but we aren't going to encourage
> > that by adding a patch like this.
> 
> Funny, I thought the class variable mechanism was a rather elegant way for
> themes to control widget geometry.

The thing is:

 - Themes are specific to one widget. I can have different widgets
   in my app with different theme engines.
 - Class variables are global to all widgets

Also, when switching themes, even if it all widgets are switched,
there is no guarantee that the first theme will be unloaded before
the second theme is loaded, so they can't coordinate changing
class variables in any coherent way.

Try switching to the metal theme and then switching to something
else - you'll find that the metal themes geometry settings stuck.
 
> > Figuring out some slightly better way for themes to do things like
> > this is something that, with any luck at all, we'll manage to do
> > for GTK+-2.0. If we do that, geometry parameters like this will
> > be one of the things that themes will be able to configure.
> 
> >From the sound of things as described by Havoc, it doesn't sound likely.
> It's a pretty big undertaking, and you're reaching a feature freeze.
> 
> I don't see what the problem is with the current approach. I mean, if theme
> engines aren't supposed to modify class variables (like
> GtkRangeClass.slider_width and GtkCheckButtonClass.indicator_size), then
> what is?  Application code? A GnomeCC capplet?  What are they there for?

Well one reason for them to be there is for subclassing. But mostly
they are there just as a way of representing a fixed global parameter
in a fairly encapsulated way, so that later con

                                        Owen