Re: Obscure timing issue

[Richard Frith-Macdonald]

On 10 Dec 2008, at 23:10, Fred Kiefer wrote:


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

I'm primarily thinking of complexity for the user/designer of  
themes ... if you have two different theme classes with different  
capabilities, then they need to pick one of them to use, and re- 
implement facilities they want from the other one (or limit what they  
can do) ... which is a real pain if they are not a programmer (and a  
waste of their time if they do know how to program)!  Separation into  
two classes cannot reduce complexity in fact ... just duplicate code.
Or ... perhaps what you really mean is two options ... one 'theme'  
which is the current hard-coded look and would never be used for  
developing themes, and another theme which does essentially what the  
current theme does and people can use for new themes, but what would  
be the point of doing that?

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

Well that's a different matter and has nothing to do with producing  
separate theme classes ... I would have said that the current theme  
code is small/simple enough to be easy to understand still, but  
nearing the point where separation for organisational purposes could  
be useful ... but that's simply separation of the class into multiple  
files with different categories in each.  The obvious break down would  
be:
1. the code dealing with loading and dynamically changing themes (this  
is the core)
2. the code providing helper methods (such as tiling)
3. the code providing gui element drawing. At the moment this really  
only implements buttons, but it's where most of the theme coding needs  
to be done, and in the long run you might even want a separate files  
for the drawing methods for each major gui element.
Now GSTheme is already broken down in precisely this manner, just not  
separated out into individual files at present.

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

That really does sound like you are advocating code duplication ...  
with a theme which can't be used for anything but drawing the  
traditional gnustep look, and another theme which follows the current  
design of drawing the traditional look but allowing people to use  
image tiling and other mechanisms to create new looks without (or  
with) any programming.
As far as I can see that has three problems ... extra work to do it,  
code duplication, and a tendency to work against development of a real  
theme engine since a lot of people would just use the traditional look/ 
feel and thus not test the theme engine at all.

> I
> don't understand, why this would force people to write code that don't
> have to do it currently.

I thought you meant code separation rather than code duplication ...  
if things were separated then people would need to write code because  
features they needed were not in the theme they were trying to use.   
If code ids duplicated, that particular issue goes away.

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

Well,  I think I understand it better now ...

> - One standard theme class that just has the current (or old) gui
> drawing code for the different user interface elements.


I'm against this because such a class *as standard* would mean that  
theme code in the gui would be tested less well, and because it would  
be duplication of code, and because it would require work to do it.

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

This is what the existing theme engine already provides ... but it's  
fundamentally not intended as a example of how to write theme bundles,  
rather it's intended as a mechanism for non-technical people to be  
able to design/develop themes *without having to write anything*!   
This is the key concept of theming ... to put it in the hands of the  
designer rather than the programmer.

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


Again, this does not go far enough.  With the current design we allow  
for these things but we also allow for theme bundles with are *not*  
subclasses and do not contain code. Such bundles are pure data,  
consisting images and defaults settings etc controlling how the  
standard theme engine draws things (currently these are the only  
themes supported by Thematic.app, but it would be nice to add support  
for subclassed themes too).
However, they depend upon the facilities in the theme engine ... so  
having a standard theme which did not support this would mean that  
we'd need extra code to automatically switch to the other packaged  
theme when necessary.

So, while none of the problems introduced by having a cut-down  
standard theme would be huge, they do amount to a compelling reason  
not to do it, given that (fro the point of view of theming at least)  
it has no advantages to counter them.