Re: Questions about the system

[Uli Kusterer]

In article <20040219233826.15108.00000028@mb-m18.aol.com>,
 willadams@aol.com (William F. Adams) wrote:

> (Apple's Appearance Manager)
> 
> I'd like to point out that this has too fine a granularity which has had a
> serious negative impact on Mac OS X's UI --- to wit, Carbon apps are
> responsible for drawing their own scroll bars, incl. placement --- because of
> this Apple was forced to put scroll bars on the wrong (right, not left) side 
> of
> windows 'cause that was where Carbon apps had them.

 The way I see it, that's probably more due to the issue of Carbon not 
having had a "scroll view" (or even a view hierarchy in the traditional 
sense) for quite a while. IMHO, the granularity is actually too coarse 
and not too fine.

 They should have had an API to get the default positions for certain 
items. E.g. a: ScrollbarRectForRect( Rect inRect, Rect* outSBRect, Rect* 
outContentRect) function would have solved that problem, and they should 
have done the same for the different parts of a scrollbar, i.e. 
UpArrowRectForScrollbarRect(), TrackRectForScrollbarRect() and the likes.

 And the same of course for buttons (rect to draw the actual button, 
rect for the title, rect for the image (aka icon) etc.), sliders (though 
those could probably be implemented by having different "styles" of 
scrollbars, and maybe renaming the API to refer to "Tracks" instead of 
scrollbars, or whatever), 

 Of course, in GNUstep one could probably just split the different 
drawing operations into different methods that get the rect to draw in 
as one of their parameters. However, to ease MacOS portability, that 
would probably better be moved into a GSButtonCell. On GNUstep, 
NSButtonCell would simply inherit from GSButtonCell. People who want 
themeability of customized views on both GNUstep and OS X could then 
just create GSButtonCells instead and take advantage of the 
GNUstep-specific features.

 And on MacOS, NSButtonCell would give you Apple's implementation, while 
GSButtonCell would map to a Aqua-ified version of GNUstep's GSButtonCell 
(from PortabilityKit).

 In case I'm not making sense: The problem of themeability is not 
actually writing a themeable button. It is to write a themeable button 
in a way that still allows creating custom controls that don't look out 
of place. For this to work, application developers need to be able to 
say: I want all the standard parts of a scrollbar, but I want to be able 
to draw some lines into the scrollbar track.

 I.e., it has to be possible to replace only the parts that you actually 
want to change, so you get as much of the theme as possible.

 Come to think of it: It may also be useful to be able to say:

[[NSColor blueColor] colorForDrawingOnColor: [NSColor 
scrollbarTrackColor]]

which would modify blueColor so it is still visible on the track. In 
Aqua, everything except white would probably go through unchanged. In a 
NeXTstep-like theme, everything except grey would probably go through 
unchanged.

 Am I making sense?

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