Re: Gnustep gui and win32 visual styles (theme)

[Richard Frith-Macdonald]

On 22 Nov 2005, at 20:17, Frode wrote:

> Hi!
>
> What is the gnustep goal about gui drawing style

To maintain a pretty faithful version of the NeXTstep look as the  
default style, while supporting a theme engine for alternative  
styling.  I think most of us want to merge Camaelon into the gui/ 
appkit as the theme engine, as it's the only theme engine we have so  
far.

> and is it possible to
> make use of native operating-system controls and menus?

As a general rule, no.  Mostly other window toolkits operate in too  
different a manner to make that feasible at all ... they won't fit  
into the event system or any of the gui frameworks.  At a very basic  
level, native functions to draw into a window may be usable.

> I'm asking because I looked at the code dealing with control drawing,
> searching for the right place to put code using
> DrawThemeParentBackground() (or the earlier DrawFrameControl()) to  
> draw
> native OS controls. I found GSDrawFunctions a good candidate for  
> this. I
> suppose the idea is to create a custom "GSWin32DrawFunctions" where  
> the
> main drawing is handled-?

Take a look at Camaelon ... I'm sure people would like to help out  
with themes support.

> Or is it possible to optimize it even further
> so that native OS can take care of much of the work? (For example,  
> like
> win32 should have an own NSButtonCell.m file?)

Using categories it's possible to have a theme bundle override parts  
of a class like NSButton to do drawing, but I don't think you can  
realistically get the native system to do more than that.

> May I should ask if there are more programmers considering and / or
> desiring this, for example porting a Mac OS X to Windows? Maybe the
> straightest way would be to tear off a project specially aimed at
> "appkit-win32" library programming and collaborate from there?

That sounds like a really bad idea from the point of view of  
GNUstep ... we want good themability, not loads of different forked  
guis.
Ideally, we should just load a theme bundle, and the gui code of each  
class would use the routines from the theme bundle to draw itsself.