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

[Robert Krawitz <rlk alum mit edu>]

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.

> 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.  What it does is require using a separate operation for
exporting, which would seem to get in the way of "speed, speed, speed".

> save + export has been designed for that, with added benefits
> of independently saving and exporting the same Work, and no more
> lost Work.

In 2.6, JPEG save already warns if the image has multiple layers.

> the success of this design is validated by the reaction of the
> target user groups, which ‘get it’ instantly, although I also
> changed _their_ keyboard shortcuts and put ‘unsaved changes’
> dialogs in their way.

-- 
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