Sven Neumann <sven@xxxxxxxx> writes: > The new GTK+ file-chooser can make use of gnome-vfs, if it is > available. I don't know about the details, but I assume that on win32, > a similar API exists and is probably used by win32 backend of the > file-chooser widget. The default behaviour of the file-chooser is not > to show remote files, but we just need to switch this restriction off. > > If we want to do that, we will however have to make the file plug-ins > use same VFS layer. Unfortunately, there is no platform-independent > VFS library yet, so we would either have to add platform-dependent > code to all file plug-ins, or write our own abstraction layer. I am > not even sure if this is feasible, but I think it would be useful to > evaluate this. I'd suggest first making the "url" plug-in optionally (if available) use gnome-vfs or any other vfs layer available on Win32, OSX etc. (in fact, I'm already about to prepare the url.c code to have multiple backends, the current code being the "wget" backend) An alternative to implementing our own vfs would be to entirely hide file handling from file plug-ins, for example by passing them already opened GIOChannels which they would use to read/write. It woud be easily possible to make the IO channels use some vfs layer and the plug-ins wouldn't even notice. While this would make "straightforward" file plug-ins (which just open, read sequentially, close) much easier to implement, it is problematic for plug-ins which want to seek around in the files a lot (like jpeg.c). GIOChannel has a seeking API, but we cannot guarantee that for all vfs backends we may want to use. We should probably try to design such a VFS/GIOChannel separation in one plug-in to see how feasible this is. ciao, --mitch
