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: Tue, 26 Jun 2007 15:38:48 +0100


On 25 Jun 2007, at 13:34, Christopher Armstrong wrote:

Hi

Richard Frith-Macdonald wrote:

On 25 Jun 2007, at 12:15, Christopher Armstrong wrote:
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.
Sorry I didn't think that Apple would expose this behaviour considering it is such a clumsy way of doing things. I don't have access to an Apple machine to experiment with. I am more inclined to just guess the behaviour and fix it later, even though it isn't the ideal solution as you outline above. The results of your experimentation would be most welcome.

Maybe they won't put the class into the public api ... but people certainly need to know what they can expect the behavior of a button to be before/after calling the methods that are in the public API. For instance, if you create a standard radio button, what gets messed up when you call setImage: (how does it show various states).

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
I was thinking it shouldn't put any images in the global namespace at all, and instead the theme provides an API to access them from GSTheme.

I guess you mean that the gui code should display system images (such as the dimple in a slider) by calling a GSTheme method rather than asking NSImage for a named image. That seems reasonable, but if we want to maintain backward compatibility, the names of system images should appear in the global namespace (perhaps we should deprecate the use of gnustep system images by application programmers though). I beleive that apple has their system images in the global namespace, and it would probably be a good (from the point of view of portability) thing for us to support the system image names that they provide. If we want theming to work properly, GSTheme *must* replace the standard system images in the global namespace with its own version (so that programmer using the system images by name in their own code will automatically conform to the new theme). However, I don't think it should add any other images to the global namespace.

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.
I have considered doing things this way but I am currently going the way I am for a few reasons:

* In order to draw like a Windows machine, we have the option of using the theming API on windows (aka "Visual Styles") or using custom drawing to do everything manually. Unfortunately we have to do both, as the theming API is not available on Win2K and on WinXP/ Vista the theme API deliberately fails when the Win98/2K theme is enabled so that controls fall back on their normal drawing which is the old style.

* We just can't sample on Windows and create tiles as it supports quite a number of themes that we will want to be compatible with.

I was thinking of sampling at runtime and noticing changes to the windows theme and automatically updating the gnustep theme info to match.

* Windows visual styles API doesn't let you retrieve the images that make up the visual style; it only lets you draw with them (under WinXP anyway).

I had assumed that, but thought you could probably draw them to a hidden window and then sample that window to find out what image is being drawn by the native theme system. That being said, I have no knowledge of windows theming, and thus no idea whether that would really work.

* For the parts where the visual styles fail, and I need to fall back on manual drawing, it is easier to confirm the results of drawing output on the OS I am targeting. I can also separate these parts and port the result back to other OS's.

Sure,.

All that said, given that I don't have access to a Mac for development, I think I will go ahead and implement something along the lines I specified above so that I can get themeing working better.

On another note, please find attached a patch that contains what I have so far in terms of theming. It is the same as last time but I've cleaned it up somewhat.

Unfortunately I still haven't had time to really look at that ... and don't know when I will get time ... certainly not today :-(






reply via email to

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