Hi, Sean Middleditch wrote: > Making the GTK file chooser use libxdg is pretty shady. Letting an > application select a file on an FTP share is pointless if the application > itself cannot actually access the file returned by the file chooser. At > best you'd have to have the chooser download/copy the file locally and > return a temporary file path to the app. But then changes to the file > would be lost. Saving the file would be difficult since when saving, the > chooser just returns the URI to the app, which again has no way to write > to any file that isn't local. > http://www.scheinwelt.at/~norbertf/dadapt/files/xdg_utils/doc/libxdg-vfs.html libxdg-vfs supports get/put functions for reading and writing files - the application just has to link libxdg-vfs. The libxdg-vfs backend for GTKFileChooser wouldn't be the default, but just for applications which use libxdg-vfs . > The xdg-vfs stuff is interesting, but until there is a complete library > that can be easily integrated into applications, there's little point in > having the file chooser support the xdg stuff. And if you have GTK apps > willing to use a VFS library, you might as well get them to go straight to > the GObject-based gnome-vfs rather than xdg-vfs. > AFAIK gnome-vfs doesn't use GObject in the API. The advantage of libxdg-vfs is, that it uses the VFS system (password storage, protocol handlers, network shares) of the current desktop (KIO *or* Gnome-VFS). Therefore your GTK application will integrate nicely into KDE without directly linking to KIO (or the other way round - a Qt application on Gnome using Gnome-VFS). Also - you don't have a whole desktop-system in the dependencies of your application - Just a little library. (If you want to use Gnome-VFS directly, you also have to link to libGnomeUI - same problem for KIO and the KDE desktop libraries). cheers, Norbert _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
