Re: [Gimp-developer] file handling, something for GIMP 2.4 ?
Hi, if we where to write a vfs for gimp the links below provide some basic information. Anyway it helped me to understand the thread. http://www.flipcode.com/articles/article_vfs01.shtml http://koti.mbnet.fi/heitsu/vfs Geert ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file handling, something for GIMP 2.4 ?
Hi, Alan Bailward <[EMAIL PROTECTED]> writes: > Maybe when accessing files through gnome-vfs files are copied to the > local system and then opened so that plugins or file ops that need to > access the file directly can. Mitch is implementing just that right now. It's already almost working in the CVS version. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file handling, something for GIMP 2.4 ?
Alan Bailward <[EMAIL PROTECTED]> writes: > Maybe when accessing files through gnome-vfs files are copied to the > local system and then opened so that plugins or file ops that need to > access the file directly can. > > Regardless of how it's done, emphasis should be put on what the user > expects to happen. In this case (IMHO as a user) the user expects > that if they can access and view the file on a sftp connection to a > remote server (through say, EOG or nautilus), they should be able to > use the gimp on the same file. That's exactly what is almost implemented in CVS HEAD. More stuff to come. > BTW, gimp 2 kicks ass, keep up the good work devs! Thanks :) ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file handling, something for GIMP 2.4 ?
Maybe when accessing files through gnome-vfs files are copied to the local system and then opened so that plugins or file ops that need to access the file directly can. Regardless of how it's done, emphasis should be put on what the user expects to happen. In this case (IMHO as a user) the user expects that if they can access and view the file on a sftp connection to a remote server (through say, EOG or nautilus), they should be able to use the gimp on the same file. BTW, gimp 2 kicks ass, keep up the good work devs! On Sun, 6 Feb 2005 11:57:52 -0500, Nathan Summers <[EMAIL PROTECTED]> wrote: > On Sun, 06 Feb 2005 17:03:20 +0100, Michael Natterer <[EMAIL PROTECTED]> > wrote: > > > 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. > > This seems like a sensible abstraction. There are two ways to handle > the seeking problem: > > 1) Just make sure that all plug-ins that need to seek handle the can't > seek error message correctly. This solution sucks. > > 2) Implement some mechanism whereby the plug-in signals ahead of time > that it needs to be able to seek around. On non-seekable streams, the > backend transparently uses temporary files (which of course can be > seeked.) > > Rockwalrus > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer > -- Alan -=|=- http://arcterex.net If you think dogs can't count, try putting three dog biscuits in your pocket and then giving Fido only two of them. --Phil Pastoret ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file handling, something for GIMP 2.4 ?
On Sun, 06 Feb 2005 17:03:20 +0100, Michael Natterer <[EMAIL PROTECTED]> wrote: > 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. This seems like a sensible abstraction. There are two ways to handle the seeking problem: 1) Just make sure that all plug-ins that need to seek handle the can't seek error message correctly. This solution sucks. 2) Implement some mechanism whereby the plug-in signals ahead of time that it needs to be able to seek around. On non-seekable streams, the backend transparently uses temporary files (which of course can be seeked.) Rockwalrus ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file handling, something for GIMP 2.4 ?
Hi, Michael Natterer <[EMAIL PROTECTED]> writes: > 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. Unfortunately some image file libraries work directly on a file descriptor. Only if the library provides a stream API, can the plug-in easily be ported to use GIOChannels. We would have to evaluate if this is the case for libjpeg, libpng, libtiff and the other major image file libraries we are using. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file handling, something for GIMP 2.4 ?
Sven Neumann <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
