On 10 Dec 2008, at 18:56, Fred Kiefer wrote:
Now that the main issue is solved (will there be a commit soon? I
expect
that this may also resolve the cursor issue we sometimes get) let's
turn
to the other two problems that Wolfgang pointed out in his mail.
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.
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.
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
