[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep themeing and MacOS HITheme APIs...
From: |
M. Uli Kusterer |
Subject: |
Re: GNUstep themeing and MacOS HITheme APIs... |
Date: |
Sat, 06 Nov 2004 04:18:24 +0100 |
User-agent: |
MT-NewsWatcher/3.4 (PPC Mac OS X) |
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