Re: GNUstep don't load images of current theme.

[Richard Frith-Macdonald]

On 18 Jul 2013, at 00:19, Riccardo Mottola <address@hidden> wrote:

> Hi,
> 
> Eric Wasylishen wrote:
>> Hi Greg,
>> 
>> There were several things we tried to do:
>> 
>> - make a clearly defined set of image names (listed in 
>> Headers/Additions/GNUstepGUI/GSTheme.h ) for themes to override. Currently 
>> we just have GSSwitch and GSRadio listed there.
>> 
>> - make the image names for themes to override describe what the image is 
>> used for (GSMenuArrow rather than common_3DArrowRight)
>> 
>> - use a standard formula for choosing the names of alternate image state 
>> (e.g. GSRadio, GSRadioSelected, GSRadioDisabled, GSRadioDisabledSelected).
>> 
> I don't think this is a good change, I thought about it. It would introduce a 
> third way of naming images.
> We have the "Next names" and we have the "gnustep names", now you would 
> introduce the "theme" names, which does complicate things even further.
> 
> While perhaps including even the "common_" prefix in the names was too much 
> (why not "theme_" or "custom_" or even nothing), I would not remap the name 
> once again. After all, a Theme cannot provide more images than gui can 
> actually handle, it can just replace them. If, for some reason, it needs "its 
> own" images for new drawing inside its code, it would need to handle them by 
> itself anyway.

The idea of making 'a clearly defined set of image names'  makes little sense 
because we already have such a set of names.

Making the image names 'describe' theor function will never work very well ... 
and in the end isn't very important.  Descriptions that work for some people, 
don't work for others, so you always need more documentation to clarify what an 
name is for.  If new names are chjosen on that basis, then next time some new 
developer comes to look at the copde, they'll want to choose new names to suit 
their own ideas.  But if you use a tool like Thematic.app, you aren't concerned 
by the actual image names anyway.

The idea of 'a standard formula for choosing the names of alternate image 
state' is good, and in general the sound of this reorganisation is nice, but in 
the end it's rather a cosmetic thing ... the actual names don't much matter, 
what matters in that the code choses the right images.

This is to say, if the code to handle image names is changed it needs to follow 
certain principles:

1. it must be backward compatible and continue to use the old image names where 
themes still use them
2. it must be OSX compatible ... not introducing new incompatible naming for 
any of the standard OSX images
3. existing GNUstep software must be updated in sync with it (ie existing 
themes and Thematic.app must be updated to support new changes)

If those three rules are followed, then old names can be phased out over a 
period of a few years, and backward compatibility code can then be removed.