GNOME Bugzilla – Bug 119545
Merge Export features into the Save dialog
Last modified: 2009-04-25 20:10:29 UTC
There are several usability issues related to the way the GIMP saves files. Several users complain that there are too many dialogs: first you get the File->Save As dialog in which you select the name and type of the file, then you sometimes get the Export dialog, then the options from the save plug-in, then some additional warnings or errors if anything went wrong. Also, many users are confused about the fact that several items in the list of file formats are grayed out, depending on whether the current image is INDEXED(A) or RGB(A). Several of these problems could be solved by integrating the Export feature into the Save dialog: a part of this dialog would be reserved for additional options that depend on the currently selected file format (and on the current extension if "By Extension" is selected). The available options in this part of the dialog would be dynamically updated if the user changes the file format or its extension. This would have the following consequences: - The user would immediately know that some conversion will have to take place, instead of having to press OK and then getting the Export dialog. - All of the options in the list of file formats would be available, and the user would know what this implies by checking if some Export options are displayed in the dialog. In addition (suggested by Sven), the Save button could switch to Export when necessary. - This would immediately solve bug #62988 (Export and WM_TRANSIENT_FOR) - This would also solve bug #75328 (ability to skip the Export dialog) - If some options can be made persistent (bug #75459), the problem would be solved in a better way than what was proposed so far (in bug #75328), because the user would always see the current value of the Export options and it would not be necessary to add a hack in the Preferences to re-show the dialogs that were skipped.
Sounds like a good way to do it. There has been many proposals on how to improve the save/export dialogs - this is the best one I've seen so far.
See also the related bug #110610 which suggest to always activate all file formats in both the "save as" and "save a copy" dialogs.
Any thoughts on the technical implications of this proposal? Looks to me that the Save dialog will need to know the user interface describing the parameter settings of all the file plug-ins. That user interface is now of course part of the plug-ins themself. If I understand this correctly we would have to extend the plug-in api so that the file plug-ins would return a UI description (maybe in XML), which the Save dialog would construct. After filling in the parameters the Save dialog would then call the file plug-in. Sounds not completely trivial to me, but of course there may be other options. I like the idea of this enhancement request, btw.
Can someone please draw a mockup of this? I doubt that putting any widgets to the save dialog is a good idea. The dialog will become overly large and complex. I vote for closing this bug report as a bad idea.
Sven, I thought that you were part of the discussion when I mentioned this idea on the last day of GimpCon2003. Anyway, the idea is to add a set of widgets below the usual parts of the save dialog. What would be included there is what you see currently in the Export dialog. Maurits: in the current code of the save plug-ins, the export part is already handled in a special way and the export dialog is created by the library, not by the plug-in itself. The interface is relatively clean, so even though the dialog is currently owned by the plug-in process (which causes the problems described in bug #62988) this could be converted to a different model in which the plug-in passes the relevant description to the core. So the plug-ins would not have to give some kind of UI description to the core. Instead, they could provide a better description of what they support when they register themselves: instead of simply RGB(A), INDEXED(A), GRAY(A), they could mention if they support single or multiple layers, layer offsets, layer boundaries that do not match image boundaries, etc. This should be enough for the core to decide what should be displayed in the export dialog.
I forgot to mention that besides the improvements in usability and feedback to the user, this feature would also reduce the code duplication: currently, each save plug-in has its own bits of code for handling the different combinations of features that could require the export dialog to be invoked. If we replace this by a better description of what is supported by the target file format, then we only need one piece of code (in the core) that handles these cases.
I never liked the idea of putting extra widgets to the Save dialog and I am sure that the useability folks will hunt you all around this planet if you propose this to one of them.
What you said about code duplication is wrong since this code lives in libgimp and is shared already. And it's definitely better perform the conversion in the plug-in, not in the core.
The code that I was refering to is the one that decides which options should be displayed in the export dialog. The code for doing the actual conversion could stay in the plug-in (although it doesn't have to). Regarding the usability, the main advantage is that the users could get direct feedback about what kind of conversion would be needed depending on the selected file format. This will also help the inexperienced users who do not know that GIF only supports indexed mode, JPEG does not support transparency, etc. In the future, it would even be better if all options from the save plug-ins could be handled by the save dialog (via some "Options..." or "Advanced options..." tab). But that would require a lot of changes in the plug-in API, so let's stick to the export options for the moment because that should be doable in 2.x. Note that this is exactly what most of the other image manipulation programs are doing (they avoid extra dialogs that pop up), so it looks like their usability people think that the options are better organized in that way.
What do you do if the user types the extension rather than choosing it from the menu? Do you watch each keystroke, and when ".jpg" appears, make all the options appear? That doesn't seem right. What does seem sensible to me would be to have a "Don't ask me again" check button on the export dialog. Incidentally, every program that I'm aware of that saves jpegs pops up an options dialog after you click on the "Okay" or "Save" or whatever button, so GIMP doesn't seem to be violating standard practices here.
How about putting this sequence (Save As dialog, Export dialog, File format options dialog) into a Wizard dialog? That could solve the potential problems with te usability police and also looks to me like a natural way to go through the `complicated' process of saving an image. This will also give the user full control over what is happening, allowing him to step back and forward.
How about putting only the export and the file format options into a single dialog? So basically just redo the current user interface, keeping the functionality in libgimp / libgimpwidgets and not touching the Save dialog in the core.
I thought about this for a while and I think that the best solution for the user interface would be to have most of the options in the Save dialog (although they do not have to be shown by default). Also, having the (customizable) presets for the various file plug-ins available directly from the save dialog would reduce the need for the users to ever see the options dialog of most plug-ins. Since this is a bit hard to explain without mock-ups and examples of how the new interface would be used most of the time, I will try to put some screenshots and explanations on a web page so that we can discuss that on the gimp-developer list.
I doubt a merge of the save dialog and the export dialog will produce cleaner UI than what we have now. Looking forward to seeing a mock-up of this enhancement request - hopefully I am proven wrong. :)
Having seen format-specific options in the save dialog of other image programs, I can say that I feel like it is somewhat of an improvement over the way we do it now.
Note: see also bug #75328 and bug #75459. These are related, but not really in a depends or blocks kind of way at this point.
I made a mock-up for this enhancement request. I used the JPEG-options, and I think the dialog will get realy big, especially if you oben one of the other expanders. I think a Properties button would save a lot of screenspace and is easyer to implement. http://hagemaenner.de/stuff/gimp/file_save.png
Thanks for the mockup but the requested feature cannot be implemented for technical reasons anyway. The file-chooser lives in the GIMP process while the file-format specific options are only known to the plug-in which runs in a different process. The only thing that can be done (and probably should be done for 2.4) is to merge the Export dialog with the file-format specific options.
Hmm. Gtk+ has a plug-and-socket mechanism that allows a widget from one application to be inserted into a container created by a different application. It seems theoretically possible to use this for solving the problem described here, although it would involve quite a bit of work in making all the various file-save dialogs consistent enough to all fit into the same space.
That's an X11 only feature and thus not an option.
Since we are going to clearly separate saving of files from exporting them this enhancement request is now obsolete, see: http://gui.gimp.org/index.php/Save_%2B_export_specification Closing as WONTFIX.