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
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
