[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Themes GNUstep
From: |
Nicolas Roard |
Subject: |
Re: Themes GNUstep |
Date: |
Wed, 31 Jul 2002 19:45:31 +0100 |
On 2002-07-31 18:52:54 +0200 Martin Häcker <mhaecker@mac.com> wrote:
>> Well, I'd like to make themes easier also, but I don't know the best way to
>> do it. Perhaps redoing the background and frame drawing functions so they
>> can be overridden, or perhaps specific (and documented) drawing methods for
>> different widgets. I was hoping someone could take the time to look at how
>> other systems implement themes and adopt that to GNUstep.
>
> Well I don't know if this is of value for you but I'd like to spend my two
> cent on this:
> I would love the theming to be bitmap theming. (I think this is also called
> skinning) By that I mean that there shouldn't be different drawing functions
> for every theme but instead a mechanism to load a different bitmap to draw
> the controls.
>
> That way the gui wouldn't loose its good user friendliness and still provide
> the main reason for themes: To look cool.
Well in fact there is two approach with Themes in a GUI Toolkit :
- skin with pixmaps
- rewrite the code
Both methods have plus and moins; pixmaps themes are simpler to make,
but normally slower. "Rewrite" themes are a bit more complex to do (it involves
programmation) but are as fast as possible.
I started by programming a bundle to change the GUI, ie, a "rewrite"
theme, because it's a good way to understand the widgets drawing relations
in GNUstep. I plan to make another bundle which could handle pixmaps themes
in the future (let me finish this one ! :).
> Doing themes that can change the behaviour of the user interface aren't such
> a good idea (IMHO) as that would just show that the original user interface
> wasn't good enough, and should be changed instead. (I know this is debatable
> but its my opinion. :)
But, rewriting the drawing functions doesn't means that the _behaviour_ will
change in any way !
>
> peace
> Martin
>
--
Nicolas Roard <nicolas@roard.com>