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 :-(
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
