[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions about the system
From: |
Uli Kusterer |
Subject: |
Re: Questions about the system |
Date: |
Sat, 21 Feb 2004 20:40:57 +0100 |
User-agent: |
MT-NewsWatcher/3.3b1 (PPC Mac OS X) |
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