Re: GtkModule fixes (#56916)

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> > The following patch I think fixes all issues for #56916.
> > 
> > The search path defaults to 
> > $libdir/gtk-2.0/<type>/major.minor.(micro-binary_age),
> > but can be augmented with the GTK_MODULE_PATH environment
> > variable.
> > 
> > If you give it a quick look over to make sure that you
> > are happy with it, I'd appreciate it.
> 
> i went over it and it looks good to me, it doesn't however
> solve the burden of the user always needing to specify
> GTK_MODULE_PATH if he went for a private installation.
> to amend that, 

If you installed a package in another path:

 How would you specify how to find the binary?
  
  - Set the PATH environment variable

 How would you specify how to find the libs?

  - Set the LD_LIBRARY_PATH environment variable

 How would you specify how to find the pkg-config files

  - Set the PKG_CONFIG_PATH environment variable.

What would I then expect to specify where to look for GTK+ modules?


There are a couple of problems with setting up the module path
in RC files:

 - We now have the machinery for having a separate RC parse
   context for each GtkSettings object. Which RC parse context
   do we get the path from?

 - If we want to load GTK+ modules before parsing RC files
   we would have a problem. (I don't think this is all that
   interesting, but we've had at least one request for it ...
   as I recall Vlad wanted to be able to have a module for
   randomized theming.)

 - If the currently loaded RC settings change, the modules
   loaded no longer correspond to the settings.

These aren't really new issues ... we have the same problems for the
module_path and im_module_file keywords currently.  (module_path
really should be theme_engine_path, im_module_path is also
a somewhat relevant keyword is only used by the gtk-query-immodules
program so doesn't have quite the same issues.)

> i think we should add a token add_module_path = "foo" in rc files
> which doesn't reset the current module path, but simply adds to
> it. with that, module installations can add and remove additional
> paths to/from ~/.gtkrc.

Well, 

 add_module_path = "foo"

would be a setting. If we wanted it to be a keyword, we'd want to
do:

 add_module_path "foo"

But I thinking editing ~/.gtkrc or /etc/gtk/gtkrc on make install
of a module is quite evil.

I also believe adding specialized keywords like this for each config
setting is pretty evil and hard to maintain. If we want to allow
things like this to be configured in the RC file, we should make
them GtkSettings. If we want to allow appending to string properties,
something like:

 module_path += ":/opt/foo/modules"

Is probably the right way to do it. All these issues floating about is
why I ducked the problem and just went with an environment variable.

Regards,
                                        Owen