One of the issues that Nicolas and I didn't find time enough to discuss
during Alpenstep was GNUstep theming and Camaelon. I will try to make up
for this in this mail.
GNUstep already has some basic theming support in the GSTheme class.
This get, at least partly used for the following classes:
GSWindowDecorationView, NSBox, NSBrowser, NSButtonCell, NSCell,
NSColorWell, NSImageCell, NSMenuItemCell, NSProgressIndicator,
NSScrollView, NSTabView, NSTableHeaderCell, NSTableView
This may look like an impressive list, but in most cases only the lowers
level of theming operations gets used. Camaelon tries to offer higher
levels of themability; on the other hand, the individual themes here
only have different images and colours, but reuse the same drawing code.
As soon as GNUstep will support pattern images in the backends, most of
the Camaelon themes could be replaced by colour lists.
The GNUstep code to draw NSCell and its subclasses has been changed and
hopefully simplified over the last months. As Camaelon is overriding
some of this code, it should be adjusted for these changes. The concept
used in NSCell is to have a specific method for each drawing operation.
Lets have a look at the central method:
- (void) drawWithFrame: (NSRect)cellFrame inView: (NSView*)controlView
{
// do nothing if cell's frame rect is zero
if (NSIsEmptyRect(cellFrame))
return;
// draw the border if needed
[self _drawBorderAndBackgroundWithFrame: cellFrame inView: controlView];
// draw interior
[self drawInteriorWithFrame: cellFrame inView: controlView];
// Draw first responder
[self _drawFocusRingWithFrame: cellFrame inView: controlView];
}
There rarely should be any need to override this method itself in themes
or subclasses.
The _drawFocusRingWithFrame:inView method already uses GSTheme to do the
actual drawing, _drawBorderAndBackgroundWithFrame:inView: still does the
drawing of the border by itself. Here extended theming may still be
needed. This of course also means that the first responder focus ring
should no longer be drawn by the drawInteriorWithFrame:inView: method.
All these methods heavily rely on the interplay between
drawingRectForBounds: and cellSize. If any theming code changes the
extend of the border of a cell, it also has to override these methods.
Sometimes this currently isn't the case in Camaelon. Of course in the
long run, we will have to add theming here as well to be consistent.
There now is also a method _drawAttributedString, which determines the
string to draw, once more a step to separate application logic from
drawing code. Please use this method, when determining the string to
draw. Expect more such changes in the future.
Another recent change was to mark more view subclasses as having a
flipped coordinate system (NSTextField, NSTableHeaderView, NSSlider,
NSProgressIndicator, NSButton). This was done to have these views behave
more similar to OpenStep and Cocoa. Of course all the drawing code in
these views needs to be adjusted for this to work. The best solution
here is to make the drawing in a cell subclass independent of the view's
flipped state. Take the NSButtonCell drawing code as an example. It
works just the same in flipped and non-flipped views.
The drawing code in GNUstep and Camaelon isn't very clean in this
respect, for example I could not easily change the code in NSTabView to
get it working with a flipped view, so I left it non-flipped. In
Camaelon you will need to change at least the NSTableHeaderView drawing
code to get it working again.
There are many other places where Camaelon needs some rework, for
example the readColorFromImage: method could use colorAtX:y: on
NSBitmapImageRep to allow for more image types. In other place more of
the code in Camaelon should be moved up into GNUstep. I hope we find
time to do this before or after the next GNUstep release. For now we
should try hard to get the Camaelon theming working again properly with
GNUstep.
My feeling is that one important first step would be to remove all the
non-flip aware methods of GraphicToolbox and force the callers to
provide the flipped state of the view. That way a lot of the drawing
code would at once be correct again.
Sorry for this long mail. The next time I will make sure to spend more
time on this issue during the GNUstep meetings to save me the burden of
writing such a long mail.
Cheers,
Fred
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
