Re: Button Cell Images

[Christopher Armstrong]

Hi

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 
> experimentation.
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.
> > 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.
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.

> 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 
back in.

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).

Regards
Chris