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]>
> > 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
> Gimp-developer mailing list
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.
Gimp-developer mailing list