Re: GNUstep themeing and MacOS HITheme APIs...

[M. Uli Kusterer]

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

> But even now it's not very hard to have your own "programmed theme" in 
> gnustep
> (like http://www.roard.com/screenshots/screenshot theme38.png) and 
> thus, I'm
> now working on a pixmap theme engine (which can reuse the same bitmaps
> as ShapeShifter's themes..).

 ShapeShifter Themes probably aren't a bad idea, though they'll 
obviously contain a menu bar, which may not be desirable. OTOH, I always 
wanted to try whether GNUstep could be coerced into displaying a menu 
bar instead of a main menu :-)

 One question, though: Do you plan to make the menu bar have a themed 
window title, like submenus? And have you ever seen one of the Rhapsody 
screenshots? In those Apple still had the NeXT menus, and the torn-off 
ones had a BeOS-like "tab" as the window title. (So it really looked 
like a torn off MacOS 9 menu, where the title can be smaller or wider 
than the actual menu) 

> I'm making progress, here is what it looks like at the moment (work in 
> progress, not all widgets
> implemented, etc.): 
> http://www.roard.com/screenshots/screenshot theme40.png

 Hey, looks great! One suggestion, though: don't use any of the 
Apple-derived themes when you get to announce a final product. Apple 
have tolerated (or ignored) that people create variations of Aqua for 
ShapeShifter, but they definitely won't tolerate if we demo GNUstep with 
it. Trouble is that most ShapeShifter themes these days don't really 
look much different than Aqua. Still, I think it's a good decision to go 
with an existing format.

> yep that could be good to check, although I think I'm starting to have 
> a fairly good idea now :)

 If you want to allow that people create custom controls that match any 
theme, you may still want to make sure you have a complete set of high- 
and low-level theme-drawing APIs. Both a call to draw a full NSTabView 
as well as a call to draw just a tab or just the body area of a tab 
view, etc. Having a look at Apple's stuff (both in HITheme.h and 
Appearance.h) is a good way to make sure nothing is overlooked.

 E.g. it'd be useful to have a call that gives positions and sizes for 
various parts relative to their view's containing rect. That would let 
people using Renaissance use a theme with completely different sizes for 
its objects. The positions of parts of a GUI element should not be 
hard-coded. A theme should be able to have the title bar at the bottom 
of the window and the close, zoom, etc. boxes in the corners of the 
window, if it so desired... (similarly for scrollers and tab views) 
Also, HITheme lets you get an HIShape (think NSBezierPath) with the 
shape of an object. That's useful e.g. when you want to let Gorm display 
some sort of focus border around a menu item (which usually wouldn't 
have one). Similarly, GORM could use that to paint a hue of blue over 
its main menu to make it distinguishable from the main menu -- that sort 
of thing.

Cheers,
-- Uli
http://www.zathras.de