discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Look and Feel


From: stefan
Subject: Re: Look and Feel
Date: Wed, 16 Feb 2005 16:02:53 +0100
User-agent: Internet Messaging Program (IMP) 3.2.2

Citát Gregory John Casamento <greg_casamento@yahoo.com>:

> Stefan,
> 
> --- stefan@agentfarms.net wrote:
> 
> > Citát Gregory John Casamento <greg_casamento@yahoo.com>:
> > 
> > <snip>
> > 
> > > Themes in GNUstep are a very different beast than in GNOME or KDE. 
> > > Typically,
> > > themes override certain portions of the drawing code in GNUstep to
> achieve
> > a
> > > new look.  GNUstep is a complex piece of work and the creation of a new
> > look
> > > for it is, by no means, a simple task. 
> > > 
> > 
> > I thought that theme support is included in GUI by a class and creating a
> > theme
> > is just replacing only that class, is not that true? AFAIR, there was such
> > class created for this purpose, or not?
> 
> This is correct.
>  

<snip>

> 
> <snip>
> 
> > Then GUI should not use drawing by using bezier paths nor DPS operators,
> it
> > should use ONLY functions from the "theme class". With this, complete
> > themability can be achieved without it being a hack, as it is now. This
> > desing
> > is much cleaner and straightforward. Theme creator does not have to dig
> into
> > the AppKit classes to find out "what should be overriden to make the theme
> > work", moreover the theme  developer will not end by uncomplete theme, as
> he
> > knows everything that he should implement.
> 
> All true.   My point was that this is not easy for the average user who
> doesn't
> know how to code.   Whereas with KDE/GNOME/etc it's a matter of creating a
> few
> textures and pixmaps etc.
> 

Yeah. I would paraphrase myself to make it clearer for others. My point was
that
AppKit should be:

1. aware of theming - presence of theming extension in AppKit
2. polite to theming - use only theme-delegated class for UI drawing

Having GUI without 1. and 2. is selfish and it is like saying: "NeXT UI is the
default, if you want yours, you are free to dig through the sources and create
your hack".

Considering KDE/GNOME/etc, we can have themes that simple by providing a
"pixmap
theme engine" on one hand. On the other hand, by having that "UI drawing
delegation" we keep open door for non-pixmap-based themes for those who know
how to code and perhaps know how to optimise their themes.

Is anyone willing to help with creation of GNUstep themability specification?
What needs to be (roughly) written before any implementation:

- list of all UI elements (not controlls, but all visible elements): ...
- list of controls and their drawing methods: ...
- map of what methods should use what UI shapes: ...
- ...

See http://mediawiki.gnustep.org/index.php/Themability and feel free to fill
missing info.

Stefan Urbanek

p.s.: I am moving this discussion to the gnustep-ui, if anyone would like to
continue in the thread, please sent it to the UI dedicated list.




reply via email to

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