Re: Default pixmap path in GTK+-1.2.8

[Marcus Harnisch <Marcus Harnisch gmx net>]

Owen Taylor writes:
 > 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.

I always wondered why GTK+ themes always have that strange gtk/
subdir :-)

So this is in fact The Better Way(tm). It is a shame that lots of
developers think that commiting to standards results in loss of their
individuality.

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

This doesn't seem to work the way I had in mind. Currently (in 1.2.x)
the *_path statements *clear* a previously set path. So if the path is
set in a global .gtkrc and the user has another *_path statement in
his ~/.gtkrc, he would end up with that final module/pixmap path
setting. I would like to make it possible to (re)construct the paths
as flexible as possible. This could be most easily achieved via the
user's environment.

But there is another argument for introducing this variable. Regarding
the fact that there *will* be an environment variable for the module
path (according to the 2.0 TODO list), users will be confused if one
*_path directive can be set via environment (module_path) while this
is not possible for the other (pixmap_path).

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

I didn't really expect the patches to actually go into GTK+-1.2.x, It
is just that I'm too lazy to download the entire CVS tree. I wanted to
test how well the changed behaviour integrates beleiving that the
differences between 1.2.x and 1.3.x in that case won't be very big
(?). Well, maybe I *should* download the CVS tree :-)

Regards,
	Marcus
-- 
	  Some operating systems are called `user friendly',
		  UNIX however is `expert friendly'.

	   Marcus Harnisch <mailto:marcus.harnisch@gmx.net>