RSS/Atom feed Twitter
Site is read-only, email is disabled

file handling, something for GIMP 2.4 ?

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

8 of 8 messages available
Toggle history

Please log in to manage your subscriptions.

file handling, something for GIMP 2.4 ? Sven Neumann 31 Jan 23:34
  file handling, something for GIMP 2.4 ? Michael Natterer 06 Feb 17:03
   file handling, something for GIMP 2.4 ? Sven Neumann 06 Feb 17:51
   file handling, something for GIMP 2.4 ? Nathan Summers 06 Feb 17:57
    file handling, something for GIMP 2.4 ? Alan Bailward 07 Feb 19:45
     file handling, something for GIMP 2.4 ? Michael Natterer 07 Feb 22:28
     file handling, something for GIMP 2.4 ? Sven Neumann 07 Feb 23:03
  file handling, something for GIMP 2.4 ? geert jordaens 09 Feb 21:15
Sven Neumann
2005-01-31 23:34:12 UTC (about 19 years ago)

file handling, something for GIMP 2.4 ?

Hi,

while we are collecting topics for a roadmap for 2.4 (and beyond), I'd like to throw another topic into the discussion. I will try to do this more often now and I'd like you to do the same. If you have specific ideas for things that you would like to work on or help others to work on them, please propose them here.

At some point, better sooner then later, we will have to pick some features and see what we can actually achieve, but we should have a nice list of options first.

OK, so what I'd like to propose is changes to the way that file plug-ins access image files, read and write them. At the moment plug-ins open the file using the standard POSIX stdio functions. This works well for local files and there is even new API in glib-2.6 that abstracts the details a bit further. The plug-ins (and gimp itself) can however not access any remote files, say on SMB shares or on a WebDAV enabled server.

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.

To be continued...

Sven

Michael Natterer
2005-02-06 17:03:20 UTC (about 19 years ago)

file handling, something for GIMP 2.4 ?

Sven Neumann 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

Sven Neumann
2005-02-06 17:51:29 UTC (about 19 years ago)

file handling, something for GIMP 2.4 ?

Hi,

Michael Natterer 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

Nathan Summers
2005-02-06 17:57:52 UTC (about 19 years ago)

file handling, something for GIMP 2.4 ?

On Sun, 06 Feb 2005 17:03:20 +0100, Michael Natterer 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

Alan Bailward
2005-02-07 19:45:46 UTC (about 19 years ago)

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 wrote:

On Sun, 06 Feb 2005 17:03:20 +0100, Michael Natterer 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

Michael Natterer
2005-02-07 22:28:27 UTC (about 19 years ago)

file handling, something for GIMP 2.4 ?

Alan Bailward 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

Sven Neumann
2005-02-07 23:03:01 UTC (about 19 years ago)

file handling, something for GIMP 2.4 ?

Hi,

Alan Bailward 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

geert jordaens
2005-02-09 21:15:35 UTC (about 19 years ago)

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