themes + engines in /usr/local

[suk <suk artax karlin mff cuni cz>]

Gtk has precompiled path somewhere inside and if gtk tries to find theme
it uses this path. The problem is worse because themes are located
separately from engines and engines location is coupled with locating
all other dll modules! 

        _gtk_get_module_path("engines");  // get_module_path in gtkmain.c

        gtk_rc_get_default_files( );

So two points how it behaves. 
1) If I install theme into /usr/local/..
        theme is in /usr/local/share/themes/...
        engine is in  /usr/local/lib/gtk-2.0/2.2.0/engines/...
   I will not see it in gnomecc and programs from distribution cannot
        use it.

So lets assume all themes and engines are in /usr/share and /usr/lib

2) If I have installed gtk compiled by me ( it's installed in
   /usr/local, because I don't want to spoil debian dist with it)
  then my programs cannot use themes, because they are link against
  gtk in /usr/local/ and

 gtk_rc_get_theme_dir() returns  /usr/local/share/themes

 gtk_rc_get_default_files( ) returns
                /usr/local/etc/gtk-2.0/gtkrc  and  
                ~/.gtkrc-2.0

 _gtk_get_module_path("engines"); returns 4 variants for each of
                ~/.gtk-2.0/.../engines and 
                /usr/local/lib/gtk-2.0/.../engines

  The only one i can set in program is gtk_rc_set_default_files( ),
which will of course not help, because gtk will find theme, but not engine.


User can tweak it changind variables GTK_PATH or GTK_EXE_PREFIX. 
But those two are changing path not only to engines, but to all 
loadable modules and I believe this is wrong. Ironicly locate the engine
is not that hard task. I think that requiring ordinary user to tweak
some variables because of this is insolence.


solution can be: 
if program can set its gtk_rc_set_default_files(...), 
        why not give him possibility to change gtk_rc_set_engine_path(...)

        not gtk_module_path 
                No, I don't want to change module_path !! Because it
                can break pixbuf-loaders etc.
So I think, that engine path can be derived from
1) static gchar**  get_module_path() as is currently
2) from gtkrc path . If we found gtkrc in /usr/loca/share/themes/ ,
        we will try if engine is in /usr/local/lib/....
        - what to do if gtkrc is found in users ~/gtkrc-..
          and in that gtkrc is still unknown engine ?
3) and maybe from some program settable point as i've said using eg.
        gtk_rc_set_engine_path()

The order of evaluation should be 3),2),1)  or  3),1),2)
This means that at startup gtk_rc_engine_path will be "", so it will
pass through it, and then most cases will be catched by 2) or 1).



By the way - there is a small bug in gtkrc.c

There is a public function
        gtk_rc_get_module_dir()
which as her gtk-doc comment says:
         Returns a directory in which GTK+ looks for theme engines.
1) to my personal taste is "module" misguiding. It should be called 
        gtk_rc_get_engine_dir or path or dirs or paths
2) engines are in fact looked up by 
         gtk_rc_find_module_in_path  
   as you can validate looking in gtktheme.c
   The mechanism in the second looks newer, because it just calls
         _gtk_find_module (module_file, "engines") 
   while the first is some historical relict, which looks as just one half 
   of the newer almost exactly cut&pasted.

However, this function is totally useless ( application has no setter ),
and therefore is unlikely that some program fails just because this
function lies.

Suk ( please cc me )

-- 
signed short            (mail)