discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep themes [Was: Obscure timing issue]


From: Andreas Schik
Subject: Re: GNUstep themes [Was: Obscure timing issue]
Date: Fri, 12 Dec 2008 10:06:50 +0100
User-agent: GNUMail (Version 1.2.0)

Hi,
please allow me to add my 2 cents here.
I second Fred in this discussion. His suggestion sounds very
reasonable to me and I think this whole discussion is just a
misunderstanding. Maybe Fred was not clear enough in first mails.

On 2008-12-12 07:02:56 +0100 Richard Frith-Macdonald
<richard@tiptree.demon.co.uk> wrote:

> 
> On 12 Dec 2008, at 00:20, Fred Kiefer wrote:
>> 
>> What I am suggesting is to separate these two concepts also in two 
>> classes.
>> What I don't see is how this would duplicate code, as these classes 
>> will
>> inherit from another and that way share most of the code.
> 
> Ah ... sounds like your design is changing ... now instead of two 
> classes we 
> have three ... a common theme class and two subclasses ...  more on 
> that 
> later.
No, he is actually proposing two classes, GSTheme and GSTiledTheme:
GSTheme, I think.

>> As you write, we don't have much methods in that class that already
>> support full theming. Lets look at one of those:
[snipped code example]
>> 
>> Half the code does the old drawing, the other half is about tiles. 
>> They
>> have nothing in common and the method would surely be easier to read,
>> when we separated them out. Which is exactly what I propose.
> 
> I don't see separating into different classes as making things 
> necessarily 
> easier to read.  Essentially there's clear separation  already, as 
> the pseudo 
> code is:
> 
> draw_button
>    if (we want to draw buttons via tiling)
>       then use tiling
>    else
>       use original drawing code
> 
> 
> Now, you could have a hierarchy with one class doing the original 
> drawing 
> code, in which case the subclass in the hierarchy would  contain the 
> tiling 
> support and your pseudo code would look like:
> 
> draw_button
>    if (we want to draw buttons via tiling)
>       then use tiling
>    else
>       [super draw_button]
> 
Which is actually easier to read. If the code does not find the tiles
it falls back to super, what ever that does. In the current situation
I first wonder what the huge switch construction is about before I
realize that it just the fallback situation I do not want to care
about in this class.

> That sort of organisation seems ok to me (it does lose the advantage 
> of 
> having all the code close together, but the subclass/superclass 
> relationship 
> is familiar, so it's easy to find the superclass code  when you want 
> to look 
> at it) I see no particular advantage to it, but  no particular harm 
> either. 
> However you have said that you should have  two separate classes (now 
> inheriting from a common superclass) with  the different drawing code 
> in 
> each:
> 
> Class1
> draw_button
>    use original drawing code
> 
> Class2
> draw_button
>    use tiling
> 
> The problem with this is that if someone is working on producing a 
> new 
> theme, and they inherit from Class1, then they can't using tiling 
> anywhere 
> in their theme unless they duplicate the particular bit of  tiling 
> code they 
> want.  If they inherit from Class2 then they can't  use the original 
> drawing 
> code anywhere to maintain a usable theme  while doing development, 
> unless 
> they duplicate code.
No. As Class2 inherits from Class1, each subclass of Class2 will
inherit from Class1 as well. Depending on how the methods are
organized Class3 may not be able to call a drawing method from Class1
directly, but
a) this is a matter of organization and
b) you usually don't have the need of calling "super super" in a class
hierarchy (I never did at least ;-).

So from a software engineering POV this code separation seems logical
to me. Have on general class for the base functionality and one or
more specialized classes on top of that.
As for using categories, this would allow for a clean separation of
code as well, but any class inheriting would inherit the tiling stuff
as well even if does not use tiles, but some other kind of drawing.

[snip]
>> 
>>>> 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.
>> 
>> As these implementation would inherit, the tile theme could just fall
>> back to the old drawing code, when there are no tiles.
> 
> Here you are contradicting yourself ...
I think Fred was simply not clear enough in the beginning of this
thread.

> Earlier in this email you said that the two theme classes would 
> inherit from 
> another, and in this and the previous email you said that  one theme 
> class 
> would use the old drawing code and one use tiling.  If  that's the 
> case then 
> (unless you have the old drawing code both in  your non-tiling theme 
> and in 
> the common superclass), your tiling code  can't fall back to the 
> drawing 
> code.  Alternatively, if the common  superclass contains the old 
> drawing code 
> then your non-tiling theme  code does nothing.
> 
> Trying to be constructive, I'd like to go back to what I said in my 
> previous 
> email about the natural organisation of GSTheme and the way  it 
> already has 
> stuff split out into categories which could in turn be  in separate 
> files. 
> If we look at how that could  reasonably be made  into separate 
> classes too:
> There is the theme loading mechanism .. this really is the heart of 
> GSTheme 
> and needs to be part of the base class.
> There is the low level drawing code (tiling, drawing a box etc) which 
> naturally falls into its own category.  This code is unlikely to be 
> overridden by people wanting to subclass GSTheme, so it could be in a 
> separate GSThemeDrawing class rather then a category (I don't see any 
> advantage to spending time doing that, over simply putting it in a 
> separate 
> file).
> Finally there are the control drawing methods (just NSButton so far) 
> which 
> could be split into a subclass and superclass simply to get the 
> tiled/untiled drawing code into separate methods.
> So you might have a class hierarchy:
> NSObject->GSThemeLoading -> GSCutDownTheme ->GSTheme
And in how far would this be different? I think you both mean
basically the same.

[snip the rest as I am not going to comment on it]

I have the feeling that you both want and mean the same, but that you
completely miss each other's point (OK, could be that I miss something
here as well :-). I believe that splitting up GSTheme into a basic
class for the basic drawing and a subclass for the drawing of the
tiles is what you both suggest (if not advocate) and IMHO this is very
reasonable.
1. It allows for a better reading of the code.
2. It allows developers of theming mechanisms to decide whether they
want to enhance tiled themeing or to invent a completely new drawing
mechanism.
3. It allows to create/design (tiled) themes w/o programming.

The current solution at least does not allow the development of new
mechanisms that do not want to use tiles at all. Each call to super
will result at least in checking for tiles before falling back to the
low-level drawing.

Cheers,

Andreas



-- 
Mail: andreas dot schik at web dot de
Home: http://www.andreasheppel.de

PGP Key is available from the MIT key server (pgp.mit.edu).

Attachment: RFC3156.txt
Description: Text document

Attachment: pgpGmJvH8XFVj.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]