gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Button Cell Images


From: Richard Frith-Macdonald
Subject: Re: Button Cell Images
Date: Mon, 25 Jun 2007 12:42:19 +0100


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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]