Hi,
Raphael Quinet <quinet@xxxxxxxxxx> writes:
> 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.
I don't think this is a good solution to your problem. It is in no
way compatible with others programs or file system layers we might
want to use in the future (like gnome-vfs for example). How is this
supposed to work with non-local files? I don't think we want to
wait for timeouts or interpret "File not found" error messages from
a web|ftp|nfs|smb server while recursively stripping off stuff from
our filename. If you want to support special filetypes that support
filesystems inside files, please stay with standards and use a
correct URI. As Nick already pointed out, the current API already
supports this sort of stuff. If it needs additions or changes, we
can of course change it now during the development cycle towards
1.4, but please let us find a reasonable solution.
> 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 current plug-in API already allows to specify any number of
additional parameters you like. As long as you document this, I
can't see why this feature shouldn't be used. It's definitely a
good solution for the non-interactive case. For the interactive
case, a GUI to choose the relevant part of the file implemented
inside the plug-in is probably what the user wants. The current
API also allows the plug-in to store arbitrary data, so you can
default to the last choice if the plug-in is subsequently used
interactively.
Salut, Sven
