[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Button Cell Images
Re: Button Cell Images
Mon, 25 Jun 2007 21:15:05 +1000
Thunderbird 18.104.22.168 (Windows/20070509)
Richard Frith-Macdonald wrote:
It's a long time since I had a chance to work on that ... I can hardly
remember myself. I think I stopped at the point where I realised I
needed to do a lot of experimentation with Apple's code to make sure
we matched it's behavior, and didn't have the time to do that
Do we really need to match Apple's behaviour? This is an undocumented
API so it shouldn't need to conform anyway as third party developers
shouldn't depend on it, especially if they're are porting code to GNUstep.
With regards to that last point I can see we have the -setImage: and
-setAlternateImage: methods. I guess if the user overrides one image and
not the other we can just leave the untouched NSButtonImageSource in
place and continue to use it. It is likely we will just use the same
instance in the _cell_image and _altImage instance variables.
From what I can see, button images are currently loaded from the
Appkit bundle by using the +[NSImage imageNamed:] API when
-[NSButtonCell setButtonType:] is called. I believe the intention is
to replace the encoding and decoding of system button images with
instances of NSButtonImageSource; there appears to be some code to do
this in NSButtonCell.m but it doesn't make any sense.
NSButtonImageSource also seems incomplete and it isn't clear what
role GSTheme plays in this.
My guess is that NSButtonImageSource instances are to be created for
each type of button (NSRadioButton and NSSwitch), and they are to be
put where -[NSButtonCell setImage:] is. NSButtonImageSource appears
to be a hidden class in Cocoa as both QuantumStep and Cocotron have
versions of it. I don't understand the part where it only gets stored
for the alternate image (not the main one as well).
Would someone kindly explain what the intention of this is and how it
should work? I have the time to work on it at the moment but I have
no idea what should happen.
The basic idea is that buttons of the standard types have to have a
default set of images to be automatically used when the button is in
various states, but the programmer can override this behavior by
setting their own image and alternate image. Apple implemented this
using a private NSButtonImageSource class to provide the images as
long as the button didn't have the images overridden by the
programmer. Exactly what the circumstances are in which the use of
the methods to set images will remove the NSButtonImageSource, and how
you can get it set for a button, are not clear without experimentation.
Greg implemented a minimal NSButtonImageSource to handle decoding of
nibs, but it doesn't really work the way Apples' implementation does,
and doesn't support theming.
What I wanted to do was produce an implementation which was consistent
with Apple's implementation, but also worked with GSTheme to provide
alternative sets of images for each default button type, so that a
theme could change the default button types cleanly. So when a button
of the default type wants to draw itssself, it asks its imagesource
for the image for the current state of the button, and the image
source provides it from a cache which it populates from the current
theme (and flushes when the theme changes).
IMHO I think we need to do the following things:
1. Maintain compatibility with existing GNUstep nibs. For this, we need
to detect when a NSButtonCell refers to an NSImage that is a stock image
and use a NSButtonImageSource instance instead. I think we can do this
by detecting when we have deserialised an image with the name
NSRadioButton or similiar, which looks like it already happens.
2. Use a NSButtonImageSource in place of an NSImage instance in
-[NSButtonCell image]. The NSButtonCell should be aware that it could
have a NSButtonImageSource or an normal NSImage instance in its _image
property. It should detect which one is there, and ask a
NSButtonImageSource instance (if present) to get the appropriate state
image if asked to draw.
3. The -[NSButtonCell setImage:] call should simply replace any existing
NSImage or NSButtonImageSource instance. We should probably do runtime
type checking to ensure that nobody tries to stick a NSButtonImageSource
4. Implement NSButtonImageSource to satisfy our needs whilst still being
compatible with Cocoa nibs. I think we can do this without much
difficulty, as the instances already retrieve enough information from
the nibs to do this (a string with the name we want). It should call
into GSTheme for the appropriate images and leave the caching upto it.
5. Modify GSTheme to handle this. Shouldn't be too difficult with the
theme image loading code already in place (although it really shouldn't
put all the theme images in the default namespace - that feature is
incompatible with this solution.
6. Modify NSButtonCell to handle NSButtonImageSource instances. This
would involve storing them when nibs are serialized (should we bump the
class version?) and loading them out when they are inflated again. We
also need to handle the theme changed events so they redraw.
Okay that reads more like an action plan but we probably want to get
this right and coding for GNUstep on Windows is painful (this is what
I'm trying to theme).