Re: Obscure timing issue

[Fred Kiefer]

Richard Frith-Macdonald wrote:
> 
> On 10 Dec 2008, at 18:56, Fred Kiefer wrote:
>> There is the GSTheme class which wastes time looking for non existing
>> tiles. Here I would suggest that we split up the class. Have the
>> standard theme class that exactly does what used to be in the gui
>> drawing code. No bells, no whistles. And a subclass of that that
>> supports tiling and other fancy theming methods. When somebody writes
>> her own theming class, she may decide which of these two classes to
>> inherit from. That way we wont have much overhead in gui through themes.
>> Any objection to that change?
> 
> Yes ... sounds like it's adding complexity (having two separate
> mechanisms to do things) and making theming harder to do and to test if
> you can't mix these things.  Especially given that the existing theme
> design already uses the standard drawing code as the default ands simply
> allows you to add other stuff as you please, and also allows people with
> no coding skills to produce themes.  I don't like the idea that people
> would have to 'write their own theming class' ... that should always be
> an option for more advanced themes, but it should not be necessary.
> 
I don't quite understand this argument. Currently we have the same
complexity (two implementations for the same thing) mixed into one
class. To me separating them into two classes sounds like a reduction in
complexity.
Looking into GSTheme.m I have the impression that half the code there is
only used when using tiled themes. Understanding this class and its
concepts could get easier by moving this code out. And with out I mean
into a separate file not removing it from gui altogether. (although
putting it into a separate bundle might be an option)
As soon as you switch your theme setting to TiledTheme.theme (or
whatever we call it) you have similar code as now, that will just fall
back to the non-tiled super implementation, when no tile is found. I
don't understand, why this would force people to write code that don't
have to do it currently.
Sorry, I can only see a big misunderstanding here. Once again the new
concept:
- One standard theme class that just has the current (or old) gui
drawing code for the different user interface elements.
- One non-standard tiled theme class, also delivered with gui (perhaps
as a bundle to demonstrate how to write theme bundles?). This will be a
subclass of the first and fall back to super calls when no tiles are found.
- Multiple theme provided by other people either subclasses of the
standard or the non-standard theme. (OK the later might get a little
harder with a bundle)

> If Wolfgang found lots of time wasted looking for tiles, thats either a
> bug, or just the first time ... the presence/non-presence of tiles is
> lazily cached in the theme so the filesystem lookup is only ever done
> once, the first time the tile would be used, and the performance
> overhead is therefore utterly insignificant.

Possible, from looking at the code I would say you are correct.