This is going to be a bit long, but here is a quick summary: I would
like to change the API to the load/save plug-ins by adding one extra
parameter. This parameter would be ignored by almost all current
plug-ins, but it would be useful for the file formats that can contain
multiple images. For example: icon files, tar files, various game
files, etc. Since this API change would probably break all plug-ins,
I would like to discuss this and get some comments. Note that I could
submit a patch for all plug-ins that are currently in the Gimp CVS,
but I cannot fix the other load/save plug-ins that are not part of the
standard distribution.
1) History of the problem
A long time ago, I started implementing some plug-ins for loading and
saving various images contained in Doom WAD files or Quake PAK files.
These files can contain many images in different formats (wall and
floor textures, sprites, skins, ...) and my goal was to be able to
edit these images directly from within the Gimp without having to
unpack and the repack the archive file using an external tool that was
slowing down the whole process. However, selecting the right image
within the file is not easy. For the file_*_load plug-in used
interactively, I can use a tree widget showing the structure of the
archive file and letting the user choose the image to edit (among
several hundreds). But this does not work in non-interactive mode and
this is annoying when saving the image, because the user must select
again the appropriate location for the image within the archive file.
I stopped the development of these plug-ins when I saw that I could
not find a user-friendly solution to this problem.
Later, I realized that the problem was common to all file formats that
support multiple images. This includes the Windows icon files,
containing multiple icons at different sizes and bit depths, as well
as the standard archive file formats such as tar and zip (these
archives could be handled at a lower level by something like
gnome-vfs, but this is not an option for icon files or game files).
2) A solution
Then I thought about CGI scripts and the environment variable
PATH_INFO that is set by the web server when the URL contains some
path information after the name of the CGI script (for example, a
script /cgi-bin/stuff gets called with PATH_INFO=/some/path if the URL
of the request is http://your.hostname/cgi-bin/stuff/some/path). This
is exactly what we need in order to support multi-image files in the
Gimp: simply add the name of the selected image to the name of the
archive file.
For example, let's say that I want to edit the image of the chainsaw
in Doom. I would tell the Gimp to open .../doom.wad/P/CSAWA0. The
Gimp would find that the real file to open is doom.wad (because this
is a file, not a directory containing a sub-directory called P) and it
would tell the WAD plug-in to open it. It would also pass the extra
path "P/CSAWA0" to the plug-in. The same would happen when saving the
file, so the plug-in would know where the image has to be saved inside
doom.wad. If I want to edit one of the floor textures in the same
file, I would tell the Gimp to open .../doom.wad/F/F1/FLOOR7_2 and the
plug-in would be called with the extra path "F/F1/FLOOR7_2".
A similar thing could be done for icon files, if we invent special
names that would identify the different images (size and bit depth)
that can be stored in an icon file. For example, one could edit
.../favicon.ico/16x16x4 (16x16, 4 bits) or .../favicon.ico/48x48x8
(48x48, 8 bits). Both of these would open the same favicon.ico file,
but a different image would be choosen inside this file.
3) Changes to the plug-in API
The File->Open dialog would behave as follows: if the given path leads
to a regular file, open it as usual (no extra path). If the path does
not exist, then try to remove the last element from the path and see
if there is a file (not a directory) with that name. If yes, open it
and pass the remaining part of the path as a parameter to the plug-in.
Repeat the shortening of the path until a valid file or directory is
found. If a directory is found, then report a failure (file does not
exist). The same thing would be done for File->Save.
In order to support this, the file_load/save API has to be changed by
adding one parameter ("extra_path" or "path_info" or something like
that). This parameter would be NULL when a regular file is loaded or
saved, but it would contain the name of the image when a multi-image
file is edited. The only thing that would have to change in the
current plug-ins is the addition of this parameter that would be
ignored.
The plug-ins for the file formats supporting multiple images would use
this extra parameter. If it is not NULL, then the plug-in would open
the corresponding image within the file. If it is NULL, then the user
has selected the whole file instead of specifying a single image from
that file. In this case, the plug-ins would pop up a tree or list
view of the file and ask the user to select the appropriate image
within that file (or report an error if the plug-in is called in
non-interactive mode). Once an image is selected, the full path would
be changed so that the user could then save the image with the usual
"File->Save" without having to redo the selection.
4) Feedback
Any comments?
-Raphael
