After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 119545 - Merge Export features into the Save dialog
Merge Export features into the Save dialog
Status: RESOLVED WONTFIX
Product: GIMP
Classification: Other
Component: User Interface
git master
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks: 118191
 
 
Reported: 2003-08-10 10:59 UTC by Raphaël Quinet
Modified: 2009-04-25 20:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Raphaël Quinet 2003-08-10 10:59:21 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.
Comment 1 Henrik Brix Andersen 2003-08-12 21:05:37 UTC
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.
Comment 2 Pedro Gimeno 2003-08-31 19:19:09 UTC
See also the related bug #110610 which suggest to always activate all 
file formats in both the "save as" and "save a copy" dialogs.
Comment 3 Maurits Rijk 2004-04-07 14:28:51 UTC
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.
Comment 4 Sven Neumann 2004-04-07 15:18:17 UTC
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.
Comment 5 Raphaël Quinet 2004-04-07 16:49:56 UTC
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.
Comment 6 Raphaël Quinet 2004-04-07 16:55:11 UTC
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.
Comment 7 Sven Neumann 2004-04-07 17:04:39 UTC
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.
Comment 8 Sven Neumann 2004-04-07 17:09:47 UTC
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.
Comment 9 Raphaël Quinet 2004-04-07 17:22:56 UTC
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.
Comment 10 weskaggs 2004-04-07 23:24:53 UTC
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.
Comment 11 Maurits Rijk 2004-04-08 08:34:26 UTC
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.
Comment 12 Sven Neumann 2004-04-08 09:03:20 UTC
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.
Comment 13 Raphaël Quinet 2004-04-14 14:25:30 UTC
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.
Comment 14 Henrik Brix Andersen 2004-04-16 10:10:33 UTC
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. :)
Comment 15 Nathan Summers 2004-04-23 21:35:27 UTC
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.
Comment 16 Nathan Summers 2004-04-23 21:40:40 UTC
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.
Comment 17 tobias 2005-01-08 17:41:14 UTC
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
Comment 18 Sven Neumann 2005-01-08 17:47:26 UTC
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.
Comment 19 weskaggs 2005-01-09 17:53:06 UTC
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.
Comment 20 Sven Neumann 2005-01-09 18:44:09 UTC
That's an X11 only feature and thus not an option.
Comment 21 Martin Nordholts 2009-04-25 20:02:55 UTC
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.