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 _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
