[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
Re: [RFC] [PATCH]: Icon themability patch for -GUI images/icons, Quentin Mathé, 2004/10/30