Re: [RFC] [PATCH]: Icon themability patch for -GUI images/icons

[Alexander Malmberg]

Basically, it seems that there are two goals here:

1. Alex Perez wants some easy way of replacing standard images.

2. Themes (represented by Nicolas, since afaik, he's the only person who 
has done any serious work on themes :) want to replace some standard 
images with their own images (presumably located in the theme bundle's 
resources).


With the current code, 1. is possible by putting images in 
~/GNUstep/Library/Images/; +imageNamed: searches that directory and will 
find use them before the ones in /System/.... Image names are generally 
of the form 'common_Foo', except for some images referenced in 
NSWorkspace which are searched for first using plain 'Foo', then 
'common_Foo'.

Alex Perez's patch simply changes this so that _all_ standard images in 
-gui are searched for first in the 'Foo' form, then the 'common_Foo' 
form. Presumably, this makes things easier for users, although there is 
a risk for name collisions. I'm ok with doing that change, but then, I'm 
also ok with switching everything over to just 'common_Foo'. However, 
unless there's some good reason for it, I'd rather not check 'Foo' and 
'common_Foo' for some images, and just 'common_Foo' for others.

I haven't checked when/why NSWorkspace was changed to search this way. 
Does anyone remember? If not, I'll go digging through cvs...


2. is currently possibly be overriding +imageNamed: (as camaelon does). 
Problem is that it's a pretty big method to override, and it has lots of 
standard handling that you'd rather not duplicate. After discussing with 
Nicolas, I think the best way to handle this is to split out the image 
loading code to a +_loadImageNamed: method. Thus, +imageNamed: handles 
aliases and caching, and themes can +poseAs: and override 
+_loadImageNamed: to intercept names. This doesn't really change 
anything, though, just makes life easier for theme developers.


The nsmapping stuff is, afaict, a mechanism for creating 
OPENSTEP-compatibility alias image names (so e.g. asking for an image 
named "NSSwitch" will get you the right GNUstep image, 
common_Switch...something).

It doesn't solve 1: I don't think it's reasonable to expect users to 
edit files for this when they can already just drop images in 
.../Library/Images/; it doesn't let you mix image sets; there's no clean 
way of updating the compatibility aliases if there are custom aliases in 
use.

It doesn't solve 2, either: the file and the images have to be in 
.../Library/Images/, so themes can't be self-contained, they'd have to 
install files all over ~/Library/Images/; it doesn't allow multiple 
themes to coexist; there's no way of keeping the compatibility aliases 
updated if a theme is using the file to map images; it wouldn't work 
with theme engine bundles where the image mappings aren't fixed.

Basically, nsmapping.strings does compatibility aliases, and that's it. 
Of course, it could be extended to do other things, but I haven't seen 
any concrete proposal to do so. I'd just as well let it die, or just 
leave it alone. FWIW, in my GNUstep apps collection, there is 1 (one) 
reference to an image name alias from nsmapping.strings, and ~100 
references to various common_* images.


<late-night-rant>
As for -gui themeability, my position is that -gui is, theoretically, as 
themeable as it'll get. You can change system colors using the defaults, 
you can change the standard images by putting your replacements in 
~/GNUstep/Library/Images/, and you can load theme bundles to do 
everything else. Further changes in -gui will be to fix bugs related to 
this and to make it easier for users/theme developers to do these things.
</late-night-rant>

- Alexander Malmberg