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

[gg <gg catking net>]

 from "Bring back normal handling of other file formats"

El 14/06/12 21:19, Graeme Gill escribió:
> "Safe" is a value judgement. The assumption being made is that preserving
> every possible detail that gimp can create overrides every other 
consideration.
>
> Many users will not agree that this is the case in every or even most 
situations.
> If they are opening a .jpg file, it's already in a lossy format, so 
it's quite
> possible (even probable) that they are happy if further loss occurs. 
If they open
> a .tiff, then they may be quite happy to save just what a .tiff will hold
> (ie. all the pixel values), and not care about what other stuff gimp has
> invented internally.
>
> Certainly the utility of an image manipulation program seems impaired if
> it can't open/edit/save an image without jumping through hoops.
>


I think the whole problem here is that there are two different uses 
which are being presented as one.

Save (as gimp internal format) and Export (to original format) is clear 
, though I would say it's back to front.

However, the ambiguity is in File | Open

In fact File | Open does not open the file for editing , it IMPORTS it, 
hence the need to export it later.

xcf saves lots of information which is useful for extended (time frame) 
work on an image. That is valuable but not always needed for shorted 
time frame work that may non the less require be non trivial, requiring 
the advanced features of gimp.

Another ambiguity is the idea of  "opening a file" when what gimp is 
really doing operating on an image, not a file.


I think what is needed to clarify the situation and remove the ambiguity 
of open/import and file/image is close to what Nicholas suggested a week 
or two back on a similar discussion introducing the idea of a "desktop". 
It did not really stick but the I think it is the key.

xcf format is a format that saves a gimp image project , in all but name.

Gimp saves lots of information about the state of gimp and state of the 
editing session and temporary layers etc that are artefacts of the work 
in progress , not the original nor final image. It is valuable to be 
able to save exactly where one is at any stage of the job and pick it up 
later without losing anything. Fine.

What this calls for is the concept of a PROJECT as distinct from a file.

In this context the current  File | Open becomes File | Import.  Then 
Save becomes save_project that will save the current _project_ including 
any layers etc that are present.  It will be clear in the interface that 
a new entity is being created and saved.

Opening a file and saving it should save the _file_ not create something 
else while _not_ saving  the file.

 File | Open would do just that and provide a mechanism for doing short 
term changes that do not require generation of a gimp project (xcf) file.

This would remove the arcane situation where one opens an image file but 
then have to export it instead of save it in order to change the actual 
file being worked on.


The advanced professional workflow would be served in the same way but 
would be explicitly presented as creating a project operating on an 
image. Then exporting the project's current content to a (flattened or 
lossy) format becomes logically coherent. Saving would be saving the 
project file (xcf).

Opening a _file_ other than xcf then indicates the explicit intention to 
operate directly on the _file_ without creating the overhead of a 
project.  Saving saves to the file. Save_As could be used if we change 
our mind and want to create a project.

It seems a lot of the current contention comes from the attempt to unite 
two conflicting workfows and inherently makes one that should be simple 
complicated.


> Certainly the utility of an image manipulation program seems impaired if
> it can't open/edit/save an image without jumping through hoops.
>

Clear differentiation between file and image project should remove the 
hoops.

/gg