Re: Default pixmap path in GTK+-1.2.8

[Owen Taylor <otaylor redhat com>]

Marcus Harnisch <Marcus.Harnisch@gmx.net> writes:

> Hi all,
> 
> while browsing the sources, I found that the default pixmap path that
> is set by GTK+ is different from the theme directory that is installed
> by `make install'.
> 
> pixmap_path is initialized to:
>   ${GTK_DATA_PREFIX}/share/gtk/themes
> 
> However, during the standard installation of GTK+ themes are installed
> into:
>   ${GTK_DATA_PREFIX}/share/themes
> 
> To be honest, I think that the first directory structure is a better
> idea as a user can easily guess from directory names that there are
> actually GTK+ themes.
> 
> Also, IMHO this variable makes sense only if someone wants to override
> theme defaults. I think that overriding defaults should be done only
> in "user space", i.e. in a user's home dir or in /usr/local for site
> configuration.
>
> The directory pointed to by pixmap_path is not created by GTK+
> installation and doesn't seem to exist at least on RH6.2. This fact
> leads to the conclusion that nobody really uses this default path,
> otherwise someone would have noticed the absence of that directory and
> would probably have discovered the difference in the sources.

Basically, the default pixmap path is wrong, and the default pixmap
path is useless. The directory from which a RC file is read from
is automatically in the pixmap path as well, and this is where
people usually put the pixmaps.

The reason for the theme structure 

 datadir/share/themes/THEMENAME/gtk

is to allow multi-themes that contain one or more window manager
themes and a GTK+ theme. The multi-theme faciltiy isn't used much (or
really at all), but I don't see changing it at this point - the
installation and structure for GTK+ is very well established
at this point.

> Don't you think we should add another environment variable, named
> GTK_PIXMAP_PATH, that initializes pixmap path? If the variable is not
> set, the compile time default would be the initial value. This
> maximizes flexibility, preserves compatibility and pushes us another
> step towards the maximum number of environment variables ;-)

I'm not really sure the point. You can always set it in your ~/.gtkrc
(or from another gtkrc file you point to from GTK_RC_FILES)
 
> I am going to create a patch to gtk+-1.2.8 over the weekend, adding
> all my proposed features.

Note that feature addition patches for GTK+-1.2.x are very
unlikely to be accepted at this point, so this is only useful
to the extent that it applies to GTK+-1.3.x. (Which is
fairly high, since I don't think this particular code segment
has been chagned.)

Regards,
                                        Owen