[Top][All Lists]

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

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

From: Nicolas Roard
Subject: Re: [RFC] [PATCH]: Icon themability patch for -GUI images/icons
Date: Sat, 30 Oct 2004 17:47:57 +0100

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

reply via email to

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