[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: |
Fri, 05 Nov 2004 13:43:09 +0100 |
User-agent: |
MT-NewsWatcher/3.4 (PPC Mac OS X) |
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