Re: Gnome-VFS, computer: and mounting

[nf2 <nf2 scheinwelt at>]

nf2 wrote:
> Alexander Larsson wrote:
>   
> > > The problem is, that i should map the list of volumes into a generic 
> > > "folder"  (It doesn't have to be "computer:"), because the Gnome-VFS 
> > > volume manager API is just too specific. I think the "data-model" 
> > > provided by libxdg-vfs should be as simple and flexible as possible, 
> > > which means a "volume" might turn up anywhere in the directory structure 
> > > of the VFS.
> > >     
> > >       
> > If you use the real APIs to list volumes and drives
> > (GnomeVFSVolumeManager) just like the computer:/// backend does you can
> > handle this however you want. I'm sure this will all be hacky and stuff
> > so you can support both KIO and gnome-vfs, but then I don't particularly
> > think that bridging KIO and vfs by adding a third API is a good idea.
> >
> >   
> >     
> Are there any better ideas to provide VFS access to cross-desktop 
> applications and their file-choosers?
>   
Ok - i'll try with a more verbose follow-up:

Yes, i think there are better (long term) solutions which i have 
outlined with my thoughts on the desktop- and the infrastructure layer here:

http://lists.freedesktop.org/archives/portland/2006-January/000088.html

With Glib-main-loop support from Qt4.2 on, it will to become a lot 
easier to move more things to a "common infrastructure layer". (and i'm 
really happy to see Qt using Glib main loop, because it might be the 
outcome of trying to convince trolltech people with my experminental 
Qt->glib patches and some discussion with them on the kdecore devel list)

What could be done for the network transpareny issue in the future:

Generally, i think both libraries - KIO and Gnome-VFS - have too many 
dependencies to desktop libraries. Therefore they are not very 
attractive for 3rd party applications.

1) bookmarks, user "mounted" network locations, passwords, etc... should 
be stored in a common way instead of using gconf or KConfig. Perhaps 
Keyring and KWallet should use the same backend library.

2) password dialogs, etc... (everything GUI related) sould be provided 
by out-of-process components instead of having to link libraries like 
libgnomeui.

3) Probably the daemon parts (which manage the state of the VFS) could 
be moved to a shared dbus service.

4) Align the behavior of protocols - especially pseudo protocols like 
system:/ should also have a representation in Gnome-VFS. Otherwise you 
can't use an URI from Konqueror in a Gnome-VFS based application.

5) The last step would be to really use the same code for protocol 
handlers.

In the meantime i think it's still worthwhile to try with an adapter 
approach like libxdg-vfs to serve 3rd party applications and 
file-choosers (and i think that a FUSE approach won't be an nice 
solution, FUSE will completely mess up the data model and hierarchy 
presented to users - but maybe i'm wrong).

Btw.: As you suggested, i have implemented a vfsroot:// folder using 
GnomeVFSVolumeMonitor (instead of using computer://) which could be 
listed the side-pane of file-dialogs. It includes the home and 
network:// folder, drives and volumes and provides drive-id's for the 
new "mount" command in libxdg-vfs. At the moment i'm struggling with 
providing directory-monitoring via libxdg-vfs, because that seems to be 
a "must-have" for file-choosers, particularly for vfsroot:// if someone 
inserts a CDROM or plugs a USB drive.

Just a comment on Gnome-VFS: I think protocol handlers should be moved 
out of the client-applications process just like KIO does it, because a 
buggy protocol handler should never crash the application. If such 
out-of-process protocol handlers had a standard IPC interface, they 
could be used from both KIO and Gnome-VFS.

Just my thoughts... I'm trying hard to understand both KIOs and 
Gnome-VFSs concepts, differences and similarities, and libxdg-vfs is a 
kind of "learning tool" ;-)

Regards,
Norbert