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

[Quentin Mathé]

Hi Richard,

Le 18 juil. 2013 à 10:18, Richard Frith-Macdonald a écrit :

> 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.

The main motivation behind the change was to make easier to port existing 
themes. For porting a pixmap theme, I think Thematic is not the right choice. 
The porting should be simple as possible: put the images in some directories 
inside a theme bundle and just edit some plist files for the name mapping. The 
approach we implemented with Eric supports this, and bring the following 
benefits:

- the image are looked up through a mapping so the image file name doesn't 
matter (you can keep the original theme image name for the image file, it's a 
very important point to make easy to port and track changes in ported themes)
- the image lookup uses a mapping that works the same for both images and tiles
- all the themed images and tiles can be known easily and clearly because they 
are listed in a single plist
- +imageNamed: continues to return the right image for old GNUstep and OpenStep 
names (looks there are still some bugs to fix here though)
- a consistent naming scheme for images and tiles (GSTheme uses 'GS or NS + 
ElementName + State' and the new image theming follows that. The element name 
doesn't really matter. What matters is using a consistent suffix imo. Using a 
standard prefix, either GS or NS would be better but is less critical)
- a central place where all the themable elements are documented as constants 
in GSTheme

Theming images was also troublesome previously, because we had to look in 
various source files such as NSButtonCell.m to understand to how to customize 
themed images. 

I would say it's not a good idea to reuse OpenStep image names, because the 
naming scheme has never really been thought for theming, and conflicts with 
GSTheme element naming rules. For example, although the name contains 
'highlighted', NSHighlightedSwitch corresponds to the 'selected' state in 
GSTheme, and the state is used as a name prefix and not a suffix (should be 
suffix if we follow GSTheme naming rules).

I really want to lower the barrier for creating new themes and porting existing 
ones. Even I as a GNUstep developer, I find it too hard to create a new theme 
and struggle each time I attempt to create one. The area that need improvements 
are imo:

- color customization (would be nice to support a single human-readable plist 
which can contain eithe RGB or Web color instead of multiple binary plists)
- improve GSDrawTile to support three or nine parts as distinct image files 
(most themes we could port don't use a single image per element but multiple 
ones)
- revise GSDrawTile to use the standard drawing functions from Mac OS X for 
three and nine part images
- consistent naming for all theme elements
- turn the GNUstep default theme into a real bundle (the theming code and the 
image lookup is more complex than it ought to be because the default theme 
isn't a real theme bundle)
- in the long run, update the GNUstep image file names to be named in a 
consistent way (very low priority)

> 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)

The change was intented to comply with 1) and 2), and not require 3). I'll fix 
the bugs in the current code and ensure it works correctly with various 
existing themes and Thematic without requiring any changes.

Cheers,
Quentin