Re: [Gimp-developer] present xcf as what it is, a gimp project file format

[Jon Nordby <jononor gmail com>]

On 17 June 2012 15:24, Robert Krawitz <rlk alum mit edu> wrote:
> On Sun, 17 Jun 2012 12:55:56 +0200, peter sikking wrote:
>>
>> I am going to summarise it because you are doing some
>> catching up in there that bloats the mail:
>>
>> - you recognise that there is a competing situation between
>> two different types of use
>
> There are more than two different types of use.
>
>> - you say there is a problem with File->Open importing non-GIMP images
>> - you have realised that xcf files are great for persisting work and
>> are acknowledging the Project reality of graphics work.
>
> Absolutely.  But sometimes the "project" is very simple, such that I'm
> very confident I'm not going to need to revisit it (or that I'm just
> going to tweak the curves or otherwise do something that doesn't need
> layers -- when GIMP has 16 or 32 bit depth, that might be a different
> matter, and if I think I might want to revisit it later, I'll simply
> save it as an XCF file).
>
> Certainly there are other tools around that are designed for simple
> things like that, but if I'm familiar with GIMP, it's easier to use the
> same tool for both.
>
>> here is my reaction to that:
>>
>> in short you want the old situation back, with the clear and
>> unambiguous working-on-a-GIMP-file workflows being secondary
>> to the one-shot png-in, png-out (same for jpeg, tiff, etc)
>> workflows. this is clear from how you label the menus.
>>
>> I have two reasons to say: no way.
>>
>> the first one is how GIMP works: it can only edit GIMP files.
>> sure, this is a superset of the simple file formats that we all like
>> to take as examples: jpeg/png/tiff. it is not for other ones
>> (ps to start with, there must be more import/export supported
>> formats that have things GIMP cannot do). the old fudge that
>> we got rid of in 2.8 is GIMP communicating that it is editing
>> a non-GIMP file, when it is not.
>
> How GIMP operates *internally* and what it presents to the user don't
> have to be one and the same.  Libre/OpenOffice use ODF as the native
> file format, but if I want to save it as a Word file, I simply Save As,
> or Save if what I originally opened was a Word file.  Internally,
> though, I believe it's operating on (a representation of) an ODF file.

You are right that there does not need to be a direct match between
the application internals and what is presented to the user. What is
important is that the user interface does not give any expectations
that the application cannot fulfill.

When LibreOffice allows you to save your work as a Word document, it
is making the user expect that the work (not just a subset of it) is
saved.
In the case of GIMP and "saving to" PNG/JPEG that is not an
expectation it can fulfill.

>> so you either import/export into GIMP format at the boundaries
>> of the GIMP app and be clear about it. this is what we do now.
>>
>> or you do your plan, build in non-GIMP-file-workflows, where for
>> each non-GIMP file type, you have to build a mode for GIMP where
>> what is on the screen matches what is in the file, right after
>> invoking Save. remember, this is the law.
>
> Why is that the "law"?  If I'm saving as a JPEG, I know that there will
> be loss.  But that's my lookout.
>
>> the second reason for saying no is checking the vision
>> and what it means:
>>
>> <http://gui.gimp.org/index.php?title=Vision_briefing>
>>
>> this makes me 100% sure that the Project/Work workflow
>> with persisted GIMP files is number one for our target
>> user groups. one-shot working is a distant second.
>
> That's fine, but how does preventing "Save" to a JPEG file interfere
> with that?  Your target audience knows that a JPEG file will lose
> information.
The target audience knows that JPEG will lose information. But if one
is basing the interaction design on that foundation, the user will be
required to not only know this, but to always keep this information in
mind when interacting with the software.

Is this a burden we want to put on the user? Will he always make the
right decision? Is it responsible software engineering to assume so?

> What it does is require using a separate operation for
> exporting, which would seem to get in the way of "speed, speed, speed".
Triggering an "export" or "overwrite" action (once you have set up the
key binding) is just as fast as a "save action".

-- 
Jon Nordby - www.jonnor.com