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

[gg <gg catking net>]

On 06/16/12 16:23, peter sikking wrote:
> Nicolas wrote:
>
> > Peter:
> > I think you misunderstood what gg is suggesting:
>
> no I did not. I pointed out some facts that close many, many routes
> in this kind of reasoning. closed and done, yes.

I too thought you were misreading what I suggested.

> let me first make a statement:
>
> _every_ time (yes, that is around a hundred times now) that I
> see this kind of user feedback (that it is normal to open a
> non-GIMP file, do some edits, then save it to the same format)
> I start to think like interaction designers should:
>
> let’s assume he is right. make it ‘just work.’

encouraging

> and every time I run into the same problems, that are giant
> usability bloopers.
>
> - to really Save the contents of the file has to match what is
> on the screen (save, quit, restart, open file: no change--undo
> history excepted). this is not just a good idea, this is the law.
> breaking the law: usability blooper.

So now you are completely ignoring what I suggested and going off 
somewhere else.

I specifically said that saving the file should be separate from saving 
the entire working state of the image. Quite clearly this will not 
preserve layers alpha etc, your "top end" target users ought be able to 
cope with out with too much difficultly

Where did this save , restart, open : no change come from? Certainly not 
what I outlined..

On the contrary I was suggesting a clear demarcation between saving the 
edit state and saving back to the original format , with all that that 
implies. That that should be both clear and logical within the interface 
and that the user retains the choice of task in hand and not be forced 
into what someone else thinks they "should" be doing.

> - this means that either all users would have to have intimate
> knowledge of file formats to know why the option to save to them
> disappear as edits are done (usability blooper. bit of alpha is
> introduced? no more jpeg; any layers? no more png; paths and
> layers? tiff is still there???) or one is doing the whole export thing
> anyway, so what is the difference (exporting is not safe, remember?)
> where are the extra hoops?
>
> - the alternative would be to limit things:

Now you are deliberately constructing ridiculous scenarios that neither 
I nor anyone else suggested in order to knock them down. This generally 
known as a straw man argument.

> > - it is 100% impossible to arrange it for popular non-GIMP files
> > (png/jpeg/tiff) there would be a mode where one could Open one,
> > make edits within the limits of the file format, and write the
> > bits straight back to a file in the same format.
>
> a multi-personality application: complete usability disaster.
>
> and that is where it stops.

I agree, functionality "modes" are definitely to be avoided. You will 
also note that I did not suggest any modal functionality to limit what 
can be done with gimp.

Another straw man.


Perhaps before dismissing my suggestion, you could actually comment on 
what I suggested rather than something else. It follows what Nicholas 
suggested recently and seems to make sense to a number of others.

An image manipulation program ought to have a simple way to handle std 
formats as someone said. I think this is what the gripes are about.

I have no preference as to actual name, whether it gets called "work" or 
"project" is immaterial , it is the function that is important.

/gg