Re: GNUstep themeing and MacOS HITheme APIs...

[M. Uli Kusterer]

In article <mailman.991.1099704922.8225.discuss-gnustep@gnu.org>,
 Nicolas Roard <nicolas@roard.com> wrote:

> actually, yes, that would be good. Well, first, this patch needs to be 
> committed, it's really nice !!
> then we could perhaps move the drawing methods to GSDrawFunctions -- 
> not only the left and
> right tabs, but also the "top" of a tab and the border.. but well, 
> we'll (I  will ?) see that later :-)

Yes, that will be helpful since the functions won't just be used for 
themeing views. E.g. if anyone ever wanted to add support for "tabbed 
windows" a la MacOS 9, these tab-drawing APIs should be useful for 
drawing the window border as well. So, it'd be nice if one didn't *have 
to* assemble a tab from several parts. I.e. there should be 
drawTabAtPoint:withName:selected:focused:, 
drawTabsAtPoint:withNames:selectedList:focusedList: (for drawing a whole 
row of tabs, takes NSArrays instead of a single object), in addition to 
drawTabInRect: and drawTabBoxInRect:. Similarly, for each of these there 
should be pathForTabWithName:selected:focused:, 
pathForContentOfTabBoxInRect: etc. methods, to allow e.g. generating a 
mask for the opaque areas of a window or to clip subviews or icons to be 
drawn on a tab. And of course boundsForTabItemForTabBoxInRect:... there 
are a lot of details that should be possible to be queried to allow for 
complex themes.

> Eh, nice idea, yes. The singleton object should perhaps be global, so 
> it will be
> easier to  access the methods (like NSApp).

 Yeah. That may also save one method call each time round, so the 
performance folks will be happy.

> It's effectively a better idea than having the themes doing a category 
> to replace the GSDrawFunctions :-)
> I'll try to implement that.

 Thanks!

> >
> > Oh, and is there any reason why GSDrawFunctions has unnamed parameters
> well, I think the reasoning was to mimick the previous NS* drawing 
> functions calls...

 Would look much cleaner with named parameters, and since this may 
eventually turn into an API used by people providing "theme plugins", 
cleaner is probably better ...

> In Camaelon now theses methods are only called indirectly, as basically 
> there are
> specific methods in GSDrawFunctions to draw each widgets. I will try to 
> commit the changes
> once the pixmap theme engine will be completed.

 Thanks, that'd be great. It's good to have both high-level and 
low-level drawing methods. E.g. the default implementation of 
GSDrawFunctions would probably contain the good old NeXTstep-ish bezel 
and groove drawing code and draw all controls in terms of that.

 New themes could then choose to just replace the groove and bezel 
drawing code, and inherit the code that implements the drawing for all 
controls from GSDrawFunctions. The basic look would stay the same, but 
have a different style.

 "Total overhauls" OTOH, could override the high-level drawing functions 
and replace the entire tab-drawing code with something of their own, 
that uses bitmaps or whatever.

 The advantage of the latter is that one could even create a subclass of 
GSDrawFunctions that called on another toolkit to render the controls. 
Haven't looked into how themeing works in GNOME or KDE, but that's the 
general direction I'm thinking. It would make it possible to have 
GNUstep apps run under KDE or GNOME but looking completely native.

Just thinking out loud here. There's definitely merit in keeping an eye 
on the performance side of things. My above detailed design would 
probably mean the drawing of every themed object gains another two to 
three method calls for determining metrics and asking the theme to draw.

However, at worst we could have two variants of GSDrawFunctions, one 
that is more optimized, and a subclass that has the methods calling each 
other to allow for more advanced themeing at the cost of some speed. 
Code duplication could be avoided by using macros or inline functions 
(which would duplicate some calls in the output, but not in the sources).

Just thinking out loud here...
-- Uli
http://www.zathras.de