Re: [Gimp-developer] Save/export, option to go back to old behaviour

[Robert Krawitz <rlk alum mit edu>]

On Mon, 19 Nov 2012 23:07:35 -0200, wanderer wrote:
> Well, I have a couple of opinions of my own for why I liked the new
> workflow.
>...
> I guess Inkscape have this same behavior (and would be a very better
> example, because it do ask before closing :P).
>
> Also, I nearly always save a file that I edited, even if it's for
> small changes. I usually keep the .xcf and the export image in the
> same folder. It's like a posture, an attitude. I don't rely on myself
> on doing things right every time, because I am a human being. So I
> prefer to choose the caution way, and I think this is the most secure
> workflow.

There's nothing wrong with that.  It's a perfectly good workflow.  It's
just not the one I (and apparently many other people) always want to
use.

My own safety mechanism is to simply never edit originals.  I always
export a copy out of kphotoalbum before editing it in any way (even EXIF
rotating it).  In fact, I keep files within my image tree read only, so
the OS protects me.  That, in fact, is one reason I like kphotoalbum: it
does not, under any circumstances, modify the file under management in
any way.  And with big projects (like panoramas or other images I care
about), I almost always edit .xcf files.  But for smaller things, or
throwaways that I'm just going to email someone or stuff on a web site,
it simply isn't worth the bother.  I know full well that editing a JPEG
file is the Wrong Thing To Do, but again, the loss of quality simply
doesn't matter in that case.  Says me, and I'm the one doing it, so I'm
right by definition :-) If someone then wants to take that JPEG, jack up
the contrast something ridiculous, and observe artifacts, tough on them.

> Of course, not everyone have to work the way I do, or plan things the
> same way I do... But if a software would have to choose for the
> default way of action, it should be the way with more caution.

I have no problem with that as a *default*.  The problem is having no
way to turn it off.

> So, for advanced users, why wouldn't it be possible to just making
> Gimp stop asking if you want to save an exported image? Well, if you
> think about the /Blender/ and /Inkscape/ case, the answer would be
> obvious - if you exported an image, you didn't saved the
> blender/svg/xcf file. So having that option native in the software
> would be a conceptual mistake by the developers. It cannot be there
> while Gimp makes that file differentiation.

And here's where we part company.  Software, like any tool, is used by
people, and putting architectural purity above usability is missing the
point.

> So, if the message box is **really** getting in the way of your
> workflow, you can uncheck the "/Confirm closing of unsaved images/"
> box in the Environment preferences. When you change to an important
> .xcf file, you check it back again. It's a little confusing I guess,
> but at least it would let you export files without being annoyed - I
> am suposing that you and the users that like the 2.6 behavior do a lot
> of quick edits instead of spending reasonable amounts of time editing
> the images. I might be wrong.

EEEK!!!!

Earlier today, I posted a comment about "alarm fatigue".  This is a
serious problem in hospitals, where there are so many alarms that are
set to such a high sensitivity that medical staff often shut them off
when they "know" that there isn't really a problem.  Unfortunately, it
leads to a good number of patient deaths:
http://www.imsbundle.com/Blog/index.php/03/alarm-fatigue-blamed-in-hospital-deaths/wireless-communications

What you're proposing here is exactly that -- disable a useful alarm and
rely on the user to then re-enable it when it matters.  One thing is,
though, it's very easy to forget to re-enable it.

If you decide that it's too dangerous to shut off confirmation of
closing unsaved images -- and that's a pretty dangerous thing to do --
you open yourself up to another data loss situation.  If your workflow
is to edit JPEG files and re-export them, you'll get a warning message
when you don't save to an XCF file.  The problem is that it doesn't tell
you whether you've actually exported to the JPEG file or not.  If you
thought you did, and you didn't, then again you've just lost your work.

And there's another danger scenario, if you do things the way the GIMP
developers intend, and always save to an XCF file.  Suppose you forget
to export back to the JPEG file (overwriting the previous version).  I
don't think GIMP warns you that you haven't exported it; there's no
reason that it should, since you may well not want to export the file
until you've done editing it.  Now, let's suppose the edit that you did
is to crop something out that you really, really didn't want to be in
there (like your credit card, with the number visible), and you post
that to the net.  Oops...

My point here is that a feature that was devised with the good intention
of preventing data loss has multiple scenarios where the feature itself,
in conjunction with common working habits, results in either data loss
or unintended data disclosure.  And don't say people should always be
careful about what they do -- they aren't, which is exactly why this
feature was devised, and the phenomenon of alarm fatigue is very real.

I sometimes do quick edits and sometimes spend a lot of time editing an
image ("reasonable" is in the eye of the beholder -- some people prefer
to process lots of images, some people prefer to craft a single image
with the utmost of care, and some people sometimes do both).  For the
latter, the new behavior is good, but for doing quick edits, it's very,
very frustrating.

> So, for closing my arguments, I think it would not be hard to do a
> *script* that checks and unchecks that save confirmation preference
> for you when you open a .xcf file and a common image file. That would
> solve the problem AND be conceptually correct, at least in my humble
> point of view (I might be wrong with the "easy to do script" part :P
> ). BUT it cannot be native to the software, that is conceptually
> incorrect - at least in my way of seeing things.

NO!  NO!  A THOUSAND TIMES, NO!!!!

Apologies for the shouting, but this is absolutely *NOT* the way to do
things!  It's a great way to lose data, since you may have both .xcf
files and JPEG files open in the same session, and you *don't* want to
change that kind of a global preference for this purpose!  The decision
about save vs. export is a decision about an individual image, although
many people may prefer to work one way or the other most or even all of
the time.

My suggestion, for what it's worth, is as follows:

By default, GIMP uses the 2.8 behavior.  However, an option is provided
such that if the user opens a non-XCF file, edits it, and saves it back
to another non-XCF format (lossy or lossless), no alarm is triggered
(unless the image contains something that the format can't handle, such
as layers, as 2.6 does).

If an XCF file is opened, or an image is saved as an XCF file, then GIMP
changes to the 2.8 behavior for that image for the duration of the
session (it's meaningless to talk about it across sessions -- if you've
saved it as an XCF file, exit, and edit the XCF file in a new session,
it's an XCF file).  No escape mechanism for that.  By editing an XCF
file, the user has clearly stated the desire to work that file in the
native GIMP format, and conversion to any other format is then clearly
an export.

As far as lossless vs. lossy image formats, though, there's a much
bigger problem than the slow decay of lossy formats (and that decay is
pretty slow if you're starting from a 98 quality setting): 8-bit
quantization.  If you're doing curve manipulations, that often bits hard
right from the get-go.  Botching a curve edit is the most common reason
to have to start over from scratch for me if I've lost the undo.  Even
if I haven't done that, it still causes severe quantization in a lot of
cases.  If the GIMP folks are worried about data loss, I suggest getting
high bit depth working ASAP.

-- 
Robert Krawitz                                     <rlk alum mit edu>

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton