Hi all,
here is a spec which claims to clean up the existent save/export features in a consistent manner.
Problems addressed:
- insufficient protection from data loss regarding layer & alpha information.
This is considered a UI bug [7]. For an example see [1].
- too many dialogs which pop up in an unpredictable manner [5]. Not a bug, but an annoyance
- obsoleted Bugs:
#75328 - Add "skip this question" to export dialog boxes.
#75459 - Add persistent defaults for the Export dialog
#119545 - Merge Export features into the Save dialog
#164709 - Export dialog should not allow to ignore mandatory export actions
Rationales:
a) the image window must be a reliable view on the image file data.
This rules out showing a .png as flagged clean while multiple layers are present [1].
b) the user's data should be protected by warnings. Usability experts disagree
here [2], but consistency with the other parts of the application is more
important within the scope of this spec.
c) format converters should follow the principle of least surprise. That means that
the image window of a re-opened converted file should look like the image window
of the original file, as closely as possible.
Notes:
- Spec Version: Draft 0.6
- Gimp 2.4.2 is referenced as current implementation.
- for clarity, the more technical term 'Export' is used in favor of
'Save_a_Copy' throughout this document. See Discussion below.
## User Interface
# Semantics from a user's point of view
Save: Store all my work. I will continue working from there or finish.
Save_as: Same as Save, possibly with a notion of changed artistic direction.
Export: Store an independent and possibly incomplete copy of my work.
I will continue working from what i have in the image window.
Regarding the workflow, Save and Save_as are inline with the workflow,
while Export means branching.
# Export
Export never touches the current image (as before). Export and Save_as form
the sole interface for file format conversions. In general, there is no need
to warn the user about conversion loss as the current image remains unchanged.
The current Export implementation lacks separation of concerns:
Format conversion means preserving as much information as possible in the new format,
following rationale c). Anything else is part of workflow automation, which should
have it's own facility with an interface of it's own (for examples see [3], [4]).
Hence the various 'Export File' pop-ups become obsolete. A future automation mechanism
might enable users to recreate the removed bits of functionality.
The interface for file sub-type specification (rgb, indexed or grayscale) is Image->Mode.
While this menu is not easily discovered in the context of format conversion, its is
relevant only for advanced users who desire optimal files.
Most users will be satisfied with the defaults (as specified in Conversion Rules below).
Steps:
1 - file selection dialog, titled 'Export image'. Former: 'Save a copy of the image'.
2 - overwrite protection (as before)
3 - internal file type conversion using a copy of the image. See Conversion Rules below
4 - file type specific settings dialog, defaults to OK (as before).
# Save
A successful Save operation syncs the image window with the file contents, flagging the image
as clean. Save and Open must be roundtrip save (not considering compression loss). Anything else
is considered unsuccessful. The File->Save menu command must be independent of the currently
selected drawable [5]. Quite ironically, the Save operations are only place were actual
data loss may happen besides the Close operation.
Steps:
1 - check if image is a new, yet unsaved one. In that case switch to Save_as (as before).
2 - check file format capabilities: if successful saving is impossible, offer alternatives in a nag-screen:
# You might loose some data: PNG plugin can't handle layers [...]
#
# | Save as .xcf | Use gimp's native format XCF, storing all your data.
# You can export your image to PNG format later on.
#
# | Export | Only store a copy of your image as PNG. Your image will remain unchanged.
#
# | Convert to PNG | Discard all data which doesn't fit into PNG format
#
# | Cancel |
3 - possible results:
- successful saving possible: do as before. The image gets flagged clean.
- 'Save as .xcf': switch to Save_as dialog with extension forced to .xcf.
The image gets flagged clean, provided saving is successful.
- 'Export': switch to Export dialog, thereby not flagging the image as clean.
- 'Convert to PNG': has the same consequences as exporting the image and
opening the exported file: all losses are reflected in the
image window and the image is flagged clean.
The ability to Undo this operation is mandatory.
- 'Cancel': as before, of course
# Save_as
differs from Save only by:
- first showing the filename selection dialog instead of Save Step 1.
- overwrite protection
- and finally updating the image's filename on successful write
(works as before regarding the diff).
# Conversion Rules:
All conversion options must be available to the wary user striving
for optimal results. Still, the ignorant user should be allowed to rely
on sensible defaults without further inquiry.
While gimp_export_image() already handles most conversion details automatically,
most of the remaining dialogs are obsoleted by following the WYSIWYG rationale c).
The individual dialogs:
1) Format can't handle layers: merge visible layers or flatten image?
common format affected: .png [3]
Always merge visible layers:
If the image has a background, the result will have a background, too.
If the image lacks a background, the result will do so as well.
2) Base type conversions
common format affected: .gif [4]
The ignorant user might pay the penalty of suboptimal files sizes.
The wary user will convert to the desired base type prior to export.
Image Type Format Capabilities Export Format
RGB 0
RGB INDEXED 1 indexed
GRAY 1
RGB 1
GRAY INDEXED 1 rgb
GRAY 0
RGB 1
INDEXED INDEXED 0 rgb
GRAY 1
3) Plug-in can only handle layers as animation frames
options: merge/flatten image, save as animation
common format affected: .gif
This case is distinct from the other dialogs:
for one of the options it is not possible to manually perform conversion
prior to export, notably the animation feature [6].
Making flatten/merge a hard-coded default would disable animations in consequence.
Making animations the default would surprise new users.
Thus, it's probably best to nag both advanced and new users by keeping this dialog,
as an exception. A future change according to [6] might obsolete the dialog.
4) Warnings dependent on current Drawable
"You are about to save a layer mask" [5] and
"You are about to save a channel"
common format affected: .jpg
These are obsoleted by the now mandatory use of the
generic export routine.
## Coda
# Workflow Examples
1) working with .xcf files: as before.
2) Simple photo editing on a .jpg
- Open
- Levels adjustment
- Crop to selection
- Save works as before. Only jpeg-compatible changes were made,
so no warning is necessary.
- Close no warning here
3) Putting Text on a .png (in-place file editing)
- Open bla.png
- Text layer created
- Export to bla.png exporting to currently opened file is admittedly ugly, but
consistent. The image stays dirty as the layer data
has not been saved.
- confirm overwrite protection
- check result in web browser
- Modify Text size
- Export to bla.png again
- confirm overwrite protection
- check result OK
- last finetuning, e.g. brightness
- Save dialog pops up, warning of layer data loss
- Convert to PNG (dialog button) layers get merged, image gets saved to bla.png
and flagged clean.
- Close no warning here
# Bonus
Nag-on-Save could educate the user about the Export/Save distinction by including
a hint like "your image has not been saved before. It has only been exported
to forgotthat.png 10 minutes ago."
Probably not worth the effort, but might become a spin-off of future workflow automation features.
# Implications
1) It must be allowed to export to a file which is currently openend.
Gimp does not monitor file modifications on disk, so this is not a problem.
See Workflow example 3)
2) Possibly the plugin-API gets broken by the modified semantics of Save.
# Unresolved Issus (Summary)
- consequences of removing the Export Dialog's Ignore button.
This button was introduced for supporting old features of save plugins (true?!?).
Currently known use cases: saving the current drawable
- Export to .gif: show 'animation or flatten' dialog?
- Naming: 'Export' or 'Save_a_Copy'?
- plugin-API affected?
- this text features too much discussion for a spec,
excluding the following section...
# Discussion
Export vs. Save_a_Copy
Despite the thorough use of 'Export' in this document, both names are considered as essentially equal.
Export emphasises format conversion, while Save_a_Copy puts the accent on workflow branching.
New users probably grasp the meaning of Save_a_Copy faster than that of the technical term Export.
For future shorthands, Export might provide cleaner namings. Consider:
Export as analogous to Save as : Export to a file
Export analogous to Save : Export to currently openend file
Export again : Repeat last export action
In any case, the dialog nomenclature must be consistent.
(currently, Save_a_Copy ends up in an 'Export File' dialog,
which in turn takes care for format conversion)
## Appendix
[1] Image window bla.png is flagged clean although there is unsaved layer information.
Steps to reproduce:
- New image
- Duplicate layer
- Save_as bla.png
- choose 'Export', then 'Save' <- The image is flagged clean, violating rationale a)
- Close <- No warning about the lost layer data,
violating rationale b)
[2] Never Use a Warning When you Mean Undo, Aza Raskin:
http://www.alistapart.com/articles/neveruseawarning
[3] PNG export shows unnecessary Export Dialog
Steps to reproduce:
- New image
- Duplicate layer
- Save_as bla.png
Export Dialog pops up with conversion options 'merge layers' and 'flatten image'.
In this case, the two options don't even make a difference.
In any case 'merge layers' is the correct behaviour to achieve minimum
surprise when opening the exported file:
- if the image has 'see through' pixels (those which are transparent in all layers),
the result will have 'see through' pixels as well.
- if the image is fully opaque, the result will be fully opaque as well.
A user who wants an opaque background will take care of that,
regardless of and prior to PNG exporting.
(Both options will merge the visible layers and discard hidden ones.
So essentially this dialog offers auto-creating a background.
Such a feature, if helpful in any way, lies in the responsability
of a workflow automation tool, not the format conversion routines.)
[4] GIF export shouldn't offer auto-conversion to grayscale
Steps to reproduce:
- New image
- Draw something with a red brush
- Save_as bla.gif
Export Dialog pops up with conversion options 'indexed' and 'grayscale'.
Following the principle of least surprise, the format conversion should
result in an indexed .gif, as this is the only way to preserve colors.
If the user wants a grayscale type .gif she has to do the grayscale conversion
manually prior to Exporting. Anything else would be a surprise, as is the current pop-up
which offers automatic grayscale conversion. Note that jpegs are handled exactly the same way.
Clearly, there are common workflows centering around a multi-layered RGB image, which
ultimatively result in a grayscale .gif. The chain of actions the user performs for
updating the .gif is often longer than just changing the mode to grayscale (e.g. includes
a resizing step). Equally clearly, automation support for these tedious 'update sidechains'
(including trailing Undo operations) is desireable, but requires a sophisticated user interface.
Implementing partial automation features via pop-ups provides the user with a very limited
interface for controlling this functionality and is annoying.
[5] The export warning "You are about to save a layer mask" depends on the
currently selected layer. This is considered unpredictable behaviour,
as File->Save_as_Copy explictly addresses the image as a whole.
Steps to reproduce:
- New image
- Duplicate layer (top layer is selected automatically)
- Add layer mask (e.g. full opacity)
- Save_as bla.jpg
Warning "You are about to save a layer mask" appears
- Cancel
- Select the Background layer
- Save_as bla.jpg
Export File Dialog appears instead of above warning
This dialog is now obsolete.
[6] This hints at making 'Animation' a GimpImageBaseType bit, so that
the image modes 'Animation RGB', 'Animation GRAY' and 'Animation INDEXED'
become available. Thus, an image could be explicitly converted to an
animation and back. As an additional advantage, the animation parameters
like the framerate could be presented as image properties instead of
querying them on saving.
[7] The risk of data loss has been implied in
http://bugzilla.gnome.org/show_bug.cgi?id=75328#c4
but is currently not filed as a bug report.
comments, flames, hugs & kisses?
sorry for the length,
peter
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
