Re: Button Cell Images

[Richard Frith-Macdonald]

On 25 Jun 2007, at 12:15, Christopher Armstrong wrote:

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

Certainly we need to match Apple's behavior if we want to make  
porting easy (the alternative is that we accept the lousy press when  
people who try to port from Apple just say GNUstep is no good because  
code that works on MacOS-X doesn't work with GNUstep).  Especially  
because Apple have a habit of updating/improving their documentation  
to include explicit descriptions of behaviors that were previously  
there but not mentioned...
So while implementing undocumented behaviors is not high on my  
priority list, I try to ensure that GNUstep matches Apple when I can.

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

Maybe, but I was not clear about exactly how buttons in cocoa behaved  
when we set one image but not the other.

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

Yes, I think so.

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

Yes.

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

Maybe ... not sure how mac programmers expect this to behave.

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

probably.

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

I agree ... the image sup[port in GSTheme needs to be enhanced to  
correctly differentiate between system images (which should be named  
and in the global namespace) and images used for tiling etc

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

I had thought that it would be good to develop a windows theme under  
gnu/linux to start with, then add backend specific features later.
By backend specific features I meant things like the ability to get  
the system colors from windows APIs and make them appear as a system  
color list in the theme, and to sample things like button images from  
the windows api, and make sections of a button image appear as tile  
images for tiling within the theme.  Such extensions could mean that  
a windows theme, when running on windows, could adapt itsself to  
conform to the native windows theming mechanisms.