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

[peter sikking <peter mmiworks net>]

gg wrote:

> I was naively expecting it to be considered and possibly discussed. Not refuted or ignored. Or attract insults.

ignored? what I did in return is spell out the basic facts
and usability considerations that put hard boundary conditions
on this design problem.

I expected you to be able to make the next step and adjust
your brainstorming idea to these conditions.

instead, you wanted to argue these away. either because you
don’t get it or because it does not suit your argument.

> So you seem to be saying this is not the place to discuss the way gimp UI is being developed.

it is, but it has to be with respect towards those who can,
and do, the contributions. if you want to be heard, stop
the continuous flow of vitriol, especially towards anything
that has a design and/or architectural approach.

now, back to your mail of yesterday, the constructive one.

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
- 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.
- you want to relabel: File->Open to File->Import, File->Save to
File->Save project
- you want a ‘new’ File->Save to to work in the old way: write to
GIMP file or export to non-GIMP file, depending on the type of file
associated with what is in the main window
- you want a new File->Open that explicitly says that this is a
non-GIMP file workflow

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.

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.

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.

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

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.

    --ps

        founder + principal interaction architect
            man + machine interface works

        http://blog.mmiworks.net: on interaction architecture