in fact nautilus says:
Aucune application n'est installée pour ce type de fichier
which should be: (+-)
no application is installed for this file type

This works fine in 2.22.0 (and SVN trunk). You probably have these issues because you did not install GVfs too, and that is required to get Computer, trash, network and all the other backends working.

gvfs is already installed

and reinstalling gvfs/gnome-vfs/nautilus ... doesn't solve anything
do you have any manual test to check if gvfs is running properly in nautilus
except from gvfs-ls/cat/tree...

I FOUND IT:
if glib is installed in /usr
but gvfs is installed in /usr/local as nautilus, then nothing works

if glib and gvfs are installed in /usr (this pollute my filesystem*)
but nautilus in /usr/local, it works


any path hardcoding ???


* a clean filesystem for me is:
dependencies follows the filesystem tree, gnome (/usr/local) require things in /usr but /usr don't require anything from /usr/local

We're hardcoding the GIO_MODULE_DIR in GLib. If you wish to build GLib and GVFS together in a different prefix, you should use --with-gio-module-dir=/path/to/other/module/dir, so that the GVFS GIO module will be loaded correctly. This isn't exactly documented anywhere except the config script for GLib, though. Maybe this should be more automatic?

I'm not sure if this is a bug or a design choice. It makes sense to me to hardcode one expected location, and allow people to load from other locations if they wish (as it's coded now).

I'll defer judgment to Alex on this one.

thanks, i did some symlinks to /usr/lib/gio/modules from /usr/local/lib/gio/modules/* and it fixed that issue.
However, could glib scan multiple modules path ? i mean /usr/lib/gio/modules:/usr/local/lib/gio/modules from $GIO_MODULE_DIR
this would really nice

Best regards

I have glib in the /usr prefix and gnome (including gvfs) in the /opt/gnome2 prefix, which I do not think is that uncommon an arrangement.  --with-gio-module-dir has no effect at all with gvfs-0.2.1 and grepping configure.ac shows that it is not a configuration option that gvfs provides.

It really should be gvfs which follows glib, and not vice versa.  The only way I have managed to get round this is as mentioned above, namely a symbolic link to /usr/lib/gio/modules.

The best approach (if gvfs is not to follow glib automatically) is to provide the --with-gio-module-dir configuration option in gvfs.

Chris

It has no effect on GVFS because it's in GLib (hence --with-gio-module-dir is for GIO to know where modules are to load them). GVFS will happily install into any directory, but GIO won't load GVFS's modules unless it knows where to find them (hence the reasoning for GIO_MODULES_DIR).

I don't think the right fix here is for GVFS to change; it should be able to be installed anywhere. I think the right fix would be to allow GIO to pick up modules from other directories. I think there's a way to do this at present by setting an environmental variable, but I can't remember what it is without grepping through GIO's source to find it.

Or you can just build GLib into your prefix as well with the correct --with-gio-module-dir. But like I said, I shouldn't be the one to make this particular call. 

As you can tell, I don't agree with you, as I think you have it back to front.

Your proposal would be most unusual.  To take an analogy, there are gnome configuration options for the dbus service and system directories - no one expects dbus to look after gnome, it is for gnome to follow dbus.

Chris

I agree but, gvfs optionally depends on gconf and gnome-keyring which are part of gnome, if such deps are used and gvfs installed in /usr, gvfs won't (probably) be usable if gnome is removed. And moreover, only gnome apps really use gvfs.

apps i have in /usr don't need gvfs nut only glib (kernel config/avahi/gamin/ hal/polkitd/consolekit)

About dbus, gnome installs some services files in /usr/local (or whatever you want), those files are part of gnome and not from dbus but dbus is looking for them in /etc/dbus-1/services:/usr/local/share/dbus-1/services (after configuration).
But DBUS still not depends on gnome, it is only able load files on demands.

If glib would be able to do the same, that would be great (only from my own personal point of view;).

In fact, the only thing i want is to have a really clean filesystem tree without cross-dependencies.


Regards
Eloi Primaux 

(In reply to comment #11)
> About dbus, gnome installs some services files in /usr/local (or whatever you
> want), those files are part of gnome and not from dbus but dbus is looking for
> them in /etc/dbus-1/services:/usr/local/share/dbus-1/services (after
> configuration).
> But DBUS still not depends on gnome, it is only able load files on demands.

See the gnome configuration options -with-dbus-sys and -with-dbus-services.  That is how gnome finds the relevant dbus directories.

Chris

(In reply to comment #11)
> I agree but, gvfs optionally depends on gconf and gnome-keyring which are part
> of gnome, if such deps are used and gvfs installed in /usr, gvfs won't
> (probably) be usable if gnome is removed. And moreover, only gnome apps really
> use gvfs.
> 
> apps i have in /usr don't need gvfs nut only glib (kernel config/avahi/gamin/
> hal/polkitd/consolekit)

Sure, but GIO can be used by anyone, and thusly through extension GVFS can be used by anyone. The system was designed specifically with this in mind. There are already KDE developers interested in a KIO-GIO bridge piece, for example. GIO could be considered "platform neutral" in this (it's a bit of a stretch but hey, other people code projects with GObjects and claim them to be desktop neutral so let's go with that), and GVFS is really no exception here. The GNOME-only dependencies are optional, and can be compiled out at build-time.

I still am not seeing why GVFS should be forced to install its module in the only blessed directory that GIO holds; you should be able to install GVFS anywhere in the system, and let applications decide if they're going to load GVFS's modules or not. GIO just has one special directory where it looks for extensions that it automatically loads, which is defined at compile time.

But like I said, the resolution of adding an environmental variable for the module search path probably makes the most sense. That way people who want to paradoxically install GLib in /usr and install GVFS somewhere silly are happy (and it's future proofed for when other people decide to start writing GIO modules, for whatever their needs might be). 

(In reply to comment #13)

> you should be able to install GVFS anywhere in the system ...

You should, and you can't.  At present, gvfs has to be installed in the prefix where the gio modules directory is.

Anyway, I think all the points that could be made have been made.

Chris

(In reply to comment #13)

i definitely agree

(In reply to comment #14)
> (In reply to comment #13)
> 
> > you should be able to install GVFS anywhere in the system ...
> 
> You should, and you can't.  At present, gvfs has to be installed in the prefix
> where the gio modules directory is.
> 
> Anyway, I think all the points that could be made have been made.
> 
> Chris
> 

Then this issue should be treated by the glib team...
cloning to glib ?

(In reply to comment #16)
>
> Then this issue should be treated by the glib team...
> cloning to glib ?

I have no idea what you mean. You say you put gnome (including gvfs) in the /usr/local prefix and glib in the /usr prefix.  In that case, what you presumably want as regards gvfs is for gvfs to accept the following compilation options:

./configure --prefix=/usr/local --with-gio-module=/usr/lib/gio/module

glib can be left as it is.  This is being made much more difficult than it really is.

Chris

when you type --with-gio-module=/usr/lib/gio/module i understand that you tell gvfs to follow glib configuration.

BUT i don't want to follow the glib configuration and i still want to install gvfs  gio modules in /whatever/lib/gio/modules

there are almost 2 reasons for that:
1) some gvfs modules aren't stable enought to be installed in /usr/lib/gio/modules
2) the way i maintain my system expect that libgioconf to be installed in the same prefix as gconf and libgiohal-volume-monitor/libgvfsdbus to be installed in the same prefix as hal and dbus.

Now, as far i understood the gio_modules_dir is hardcoded in glib
(comment 9)
> It has no effect on GVFS because it's in GLib (hence --with-gio-module-dir is
> for GIO to know where modules are to load them)

Then if i want to use multiple gio modules directory i need to add this to glib.

That's why i said it was then a glib issue

Clearly not gvfs, but *if at all* glib. Glib provides a extension mechanism to install extensions for it in the much the same way that any other piece of software does, like e.g. nautilus has a single nautilus extension path, evolution has an EPlugins dir, etc. pp., and even the linux kernel has a very well known directory to load its modules from. Most of the extensions path from GNOME software are advertised through the pkg-config files. So is the giomodule path in gio-2.0.pc. From gvfs POV we just use that to bring native volume monitoring, AppInfo functionality and the whole remote file access functionality to gio by installing exactly three modules into the very well known giomodule path. I don't see why you would want any of those three installed somewhere else. That we are using hal or gconf is an implementation detail that should and is hidden away from the user by gvfs. They don't belong to hal, dbus or gconf but to gvfs. We are just utilizing that libraries to implement functionality. (I also don't get you first reason, if any of those 3 modules are really unstable, we should totally fix that since they are crucial, maybe you are confusing gvfs-gio modules with gvfs backends here?)

That said and although I don't see a good reason why one would really want it, maybe having an env variable to add additional modules paths for setup like yours doesn't hurt that much. Of course loading small files from various locations on the filesystem (leading to seeks) is surly not good for performance, but most distribution wouldn't do it that way anyway.

If you want to hack int the stuff yourself for now, look at giomodule.c in glib/gio. I had a quick look and it shouldn't be too hard to hack into, since its already modularized in a good way.

(In reply to comment #19)
> ... So is the giomodule
> path in gio-2.0.pc. From gvfs POV we just use that to bring native volume
> monitoring, AppInfo functionality and the whole remote file access
> functionality to gio by installing exactly three modules into the very well
> known giomodule path.

However, gvfs doesn't do this at the moment.  It installs its modules into $libdir/gio/modules (using the path in its own Makefile) whatever the path in gio-2.0.pc.  This is what began this thread.  It seems to me that it either needs to follow the path in gio-2.0.pc, or provide a --with-gio-module-dir compile option.

I agree with all your other sentiments.

Chris

Chris, you are right. I either have misunderstood some of the statements here or not everyone does want the same thing. I filed the giomoduledir .pc file issue under bug #523852. If that is really all you guys want, just close that bug here. Thanks.

Not everyone wants the same thing, and the argument became convoluted to the point that this (to me) fairly obvious point was in danger of getting lost.  But it is what I want! Thanks.

As I didn't start the bug, though, I will leave someone else to close it.

Chris.

Ok then, i will hack myself(*) giomodule.c to fit my needs: making glib to read the GIO_MODULES_DIR(S) environment var if it exists.

Thanks for all

(*) won't be so easy for me but "qui ne tente rien n'a rien" = "Who tempts nothing has nothing"

I came up with this one the other day but haven't given it a thorough test yet (too busy). 

Index: gio/giomodule.c
===================================================================
--- gio/giomodule.c	(revision 6747)
+++ gio/giomodule.c	(working copy)
@@ -300,6 +300,7 @@
   GList *modules, *l;
   static gboolean loaded_dirs = FALSE;
   GIOExtensionPoint *ep;
+  const char *module_path;
 
   G_LOCK (loaded_dirs);
 
@@ -329,6 +330,23 @@
       
       modules = g_io_modules_load_all_in_directory (GIO_MODULE_DIR);
 
+      module_path = g_getenv ("GIO_EXTRA_MODULES");
+
+      if (module_path)
+        {
+          int i = 0;
+          gchar **paths;
+          paths = g_strsplit (module_path, ":", 0);
+    
+          while (paths[i] != NULL)
+            { 
+              modules = g_list_prepend (modules, g_io_modules_load_all_in_directory (paths[i]));
+              i++;
+            }
+
+          g_strfreev (paths);
+        }
+
       /* Initialize types from built-in "modules" */
 #if defined(HAVE_SYS_INOTIFY_H) || defined(HAVE_LINUX_INOTIFY_H)
       _g_inotify_directory_monitor_get_type ();

(In reply to comment #23)
> 
> (*) won't be so easy for me but "qui ne tente rien n'a rien" = "Who tempts
> nothing has nothing"

Attention des faux amis!  "tempt" = seduire.

Chris

Oups... i should check twice what i wrote, thanks
corr: "who try nothing has nothing" (better:)

Regards

(In reply to comment #24)
> I came up with this one the other day but haven't given it a thorough test yet
> (too busy). 
> 
> Index: gio/giomodule.c
> ===================================================================
> --- gio/giomodule.c     (revision 6747)
> +++ gio/giomodule.c     (working copy)

working for me

That patch looks good to me. 

Committed.
2008-03-28  A. Walton  <awalton@svn.gnome.org>

	* giomodule.c (_g_io_modules_ensure_loaded):
	Adds GIO_EXTRA_MODULES environment variable support, closing bug 
	#523039.