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

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 
   the image window of a re-opened converted file should look like the image 
   of the original file, as closely as possible.

- 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 
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 
following rationale c). Anything else is part of workflow automation, which 
have it's own facility with an interface of it's own (for examples see [3], 
Hence the various 'Export File' pop-ups become obsolete. A future automation 
might enable users to recreate the removed bits of functionality.

The interface for file sub-type specification (rgb, indexed or grayscale) is 
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).

1 - file selection dialog, titled 'Export image'. Former: 'Save a copy of the 
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.

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 
    #                          You can export your image to PNG format later 
    #    | 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 
    #    | 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 
     - '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 
                         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 

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 
    Making animations the default would surprise new users.

    Thus, it's probably best to nag both advanced and new users by keeping this 
    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 
                           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 
    - Convert to PNG (dialog button)    layers get merged, image gets saved to 
                                        and flagged clean.
    - Close                             no warning here    

# Bonus

Nag-on-Save could educate the user about the Export/Save distinction by 
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 
  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 
    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:

[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 
    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 
      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 
    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 
    but is currently not filed as a bug report.

comments, flames, hugs & kisses?

sorry for the length,

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Gimp-developer mailing list

Reply via email to