[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: Alexander Malmberg
Subject: Re: [RFC] [PATCH]: Icon themability patch for -GUI images/icons
Date: Mon, 01 Nov 2004 01:31:57 +0100
User-agent: Mozilla Thunderbird 0.8 (X11/20040926)

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.

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.

- Alexander Malmberg

reply via email to

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