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

 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]