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

[Nicolas Roard]

Le 30 oct. 04, à 16:16, Fred Kiefer a écrit :

> Alex Perez wrote:
> > This patch builds upon a previous non-behavior-changing patch which I 
> > wrote and Alexander Malmberg comitted this morning on my behalf. For 
> > some background:
> > NSWorkspace had a private convenience class called _getImageWithName: 
> > which, with the permission of Alexander Malmberg, we moved to NSImage 
> > and renamed to -standardImageWithName: and modified slightly so the 
> > alternate: argument was not necessary (it now intelligently looks for 
> > "ImageName" and then for "common_ImageName" (and anything else for 
> > that matter, like "camaelon_ImageName", if you override the method.) 
> > In any event, What this patch does is enable icon themability. You 
> > can have sets of icons which you can use by simply having a very 
> > small bundle override the -getImageWithName: method.
> > This patch builds upon the previous one, by making nearly every 
> > single image which was previously loaded directly via NSImage 
> > -imageNamed: "common_ImageName" load with the new convenience NSImage 
> > method.
> > Unless you want your own icon set, you will notice zero behavioral 
> > change.
> > Everyone, please comment on this...If I don't hear anything negative 
> > from anyone by tuesday or so of next week, I will commit it as-is. It 
> > works on my machine.
>
> Sorry to repeat myself, but NSImage has been themable all the time. 
> There is the file nsmapping.strings in gui/Images, which defines which 
> file name will be used instead of a given image name. What else would 
> you need for themability?
> Yes, the problem is that this feature is currently not widely used in 
> GNUstep GUI and in the GNUstep applications. Hard coded image names 
> are often used in them. Do you expect the introduction of an 
> additional API, which you even expect to be overwritten in theme 
> bundles to resolve this?

I'm not sure this patch is really useful, in fact. Basically, if we 
want to look first on user's directory for icons, we can just add that 
in imageNamed ...
If we want to get rid of the common_* names, well, then we should apply 
the patch or something similar. But is it really needed ? having 
common_* names doesn't really step on namespaces... Although it can be 
nice to doesn't require common_ prefix.. but I don't see it as really 
important. What's your opinion ? do we need a special method for 
"system icons" or can we just stick with the common_ prefix ? 
Personally I think sticking with the common_ prefix is ok. Perhaps 
change it to another prefix like "system_" or "systemIcons_" to have a 
clearer name, but that's all... that way we keep the mechanism simple.

Else... looking firs in user's directory is effectively a method for 
the user to "theme" the icons. But it's not that good, for example with 
multiple "icon themes", the user will need to manually extract the 
icons and put them in his directory. Not as easy as it could be done 
with a proper theme management.

In the end, my opinion is that it will probably be simpler to just 
handles the responsability of icons themes and their management to a 
gui bundle (ie, Camaelon for example, as it already intercept icons 
that way..).

By the way, I think it will be nice to get rid of the nsmapping.strings 
file -- it add complexity for not much added value imho.

> Sorry, I am actually getting bored of this and most other 
> pseudo-discussions going on in the GNUstep mailing lists. Perhaps I 
> should think about dropping out of them.

?

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
 -Arthur C. Clarke