Re: GNUstep themes [Was: Obscure timing issue]

[Fred Kiefer]

Yes most of this discussion was just a misunderstanding. What I tried to
propose, but failed to, was as simple new class layout:

NSObject -> GSTheme -> GSTiledTheme -> CustomTheme1
              |
              \->CustomTheme2

Where we would only provide the first three classes.

GSTheme will contain the old gui drawing code, plus some theme
infrastructure.

GSTiledTheme will contain tiled based drawing that falls back to GSTheme
drawing when no tiles are provided for the specific case.

This really is what I wanted to write in the first mail, I just
shouldn't write mails that late. In the future I will stick with coding
at that time :-)

Fred

Richard Frith-Macdonald wrote:
> On 12 Dec 2008, at 09:06, Andreas Schik wrote:
>> No. As Class2 inherits from Class1, each subclass of Class2 will
>> inherit from Class1 as well.
> 
> That was my suggestion ... Fred said 'these classes will inherit from
> another'
> 
>> And in how far would this be different? I think you both mean
>> basically the same.
> 
> Maybe so.
> 
>> The current solution at least does not allow the development of new
>> mechanisms that do not want to use tiles at all.
> 
> It does ... the new mechanisms simply don't need to use tiles.  I have
> test code that does that.
> 
>> Each call to super
>> will result at least in checking for tiles before falling back to the
>> low-level drawing.
> 
> True ... but that's invisible to the developer and a negligible overhead
> and it's a requirement for the general case (for other people to be able
> to alter/enhance the theme any way they like).
> 
> If a theme developer really wants to prevent other people from producing
> their own themes based on his/her theme than they can override the
> drawing code completely, but otherwise (what I'd consider a well behaved
> theme) their code would call the superclass implementation when thy
> don't want to do anything special.
> In fact, it's perfectly reasonable to implement a theme in which a
> drawing method will do some preliminary setup, then call the superclass
> implementation, then do some extra drawing on top of that.