Hi

Liam R E Quin wrote:

Consider

(1) open typewriter.jpg that came in from my camera (2) do some fun editing
(3) save-as to go to typewriter2.xcf.gz

So far so good.

(4) now I want to make a jpeg so other programs can use the file, so I can upload it on the Web, etc. Aha! there's File->Export to typewriter.jpg,right there in the file menu. I do this, not noticing that it's using the OLD filename,and the file is overwritten with no confirmation. Because jpeg is lossy, I can't now get back the original (actually it was backed up)

The purpose of that menu entry is to allow quick touchups of photos. You open e.g. a jpg, do some change, then export back to the original file. It wouldn't make sense to ask for overwrite confirmation. But we should look into how to minimize the risk of accidental usage since I would say the data loss you describe is severe.

OK, let's suppose I learned my lesson and change to (4) use file->Export.
GIMP has forgotten my new filename (typewriter2.jpg)

The filename of the original file has higher priority than the filename of the last saved XCF when exporting, so we'll need to change the spec here if we don't want the current behaviour.

, and has also
forgotten that where opened the file (and saved the xcf.gz), and wants me to put the new jpeg file in ~/Documents.

If you didn't export any file previously to ~/Documents then this is a bug, because as third priority the path of the original file shall be used as the default for the export dialog. Prio one is path of the last export of the file, prio two is the path of the last export of any file. I did a quick test and wasn't able to reproduce the bug, so I will need a step-by-step on how to reproduce this in a new GIMP session.

Obviously it's not supposed to work like this. I think it should be (1) I load typewriter.jpg
(2) Save would make typewriter.xcf.gz (3) Save-as would change "typewriter" to some other prefix I chose, e.g. "funky-keys"
(4) "export to" should now say, Export to funky-keys.jpg

"Export to" is a shortcut to export to the original file or the most recently exported file. I don't think it is a good idea to change its path if you save a file because it would switch all the time. You save, it changes, you export, it changes, you save, it changes again. You would not be able to consistently use Ctrl + S for save and Ctrl + E to export.

(5) the export to dialogue should bring up the file chooser in the same directory as funky-keys.xcf.gz but with the new name filled in, and that name should be funky-keys.jpg, because I changed the name. (6) "export..." should bring up the file chooser in the same directory as funky-keys.xcf.gz, again with funky-keys.jpg by default.

First of all, there is no "export to dialoge", I assume those are duplicates of the same point. Why is it wrong to assume that the user wants to export to a file in the vicinity of the original file? And if that is wrong, you correct it, and it will make a better guess the next time. I don't think we should change the default path/name/type priorities in this particular situation.

(7) after saving, there must be visible indication that the image is not changed since export. E.g. the * should go away from the title, or there could be an annotation in the undo history to show the filename, or the status bar could say "exported to funky-keys.jpg in /media/thumbdrive6/typewriters"

The * should definitely go away after you save. It doesn't do that for you? If it doesn't, then that is another bug. What is the step-by-step in a new GIMP session?

(8) if I am saving to a filename other than the CURRENT filename shown in the title bar, and the file exists, I must be warned and asked if I want to overwrite the file.

I assume you meant to write ".. I must be warned and asked if I want to overwrite the file when I do an "Export to"? If that is what you meant, then maybe that is a good idea. Peter, what do you think? If you literally meant what you write then yes it should definitely ask you if you want to overwrite a file that already exists and if it doesn't, then that is a bug. It seems to work for me. What is the step-by-step?

However, a repeated export to the same file, with no intervening "save as" to change the filename, needn't warn me. Or there could be a checkbox, "don't warn again for this filename for this particular image, in this gimp session"

Please let's not have any such insecure message boxes in GIMP. GIMP should be confident in what it is doing.

BR, Martin

Liam R E Quin wrote:

I'm not filing this as a bug yet, because I'm not sure if it's a bug in the code or in the spec or in my feeble brain... or if the spec isn't up to date with people's ideas...

I forgot, here is a link to the spec: http://gui.gimp.org/index.php/Save_%2B_export_specification

I think we can have a better discussion if we discuss the spec rather than the implementation of it. Once we agree on the spec we can start to point out bugs.

/ Martin

Martin Nordholts wrote:

Hi

Liam R E Quin wrote:

Consider

(1) open typewriter.jpg that came in from my camera (2) do some fun editing
(3) save-as to go to typewriter2.xcf.gz

So far so good.

(4) now I want to make a jpeg so other programs can use the file, so I can upload it on the Web, etc. Aha! there's File->Export to typewriter.jpg,right there in the file menu. I do this, not noticing that it's using the OLD filename,and the file is overwritten with no confirmation. Because jpeg is lossy, I can't now get back the original (actually it was backed up)

The purpose of that menu entry is to allow quick touchups of photos. You open e.g. a jpg, do some change, then export back to the original file. It wouldn't make sense to ask for overwrite confirmation. But we should look into how to minimize the risk of accidental usage since I would say the data loss you describe is severe.

So there is a problem between what the "purpose" was intended to be and the way it is seem by the user who does not know this intended purpose. That would seem to be a clear design flaw and an assumption that the user knows what the designer intended.

OK, let's suppose I learned my lesson and change to (4) use file->Export.
GIMP has forgotten my new filename (typewriter2.jpg)

The filename of the original file has higher priority than the filename of the last saved XCF when exporting, so we'll need to change the spec here if we don't want the current behaviour.

Then I think the spec needs rewriting. It is clearly illogical for the user to select save as jpg and get a default filename that is not jpeg. This idea of priority may need re-examining or just that the priority here is not the correct one.

, and has also
forgotten that where opened the file (and saved the xcf.gz), and wants me to put the new jpeg file in ~/Documents.

If you didn't export any file previously to ~/Documents then this is a bug, because as third priority the path of the original file shall be used as the default for the export dialog. Prio one is path of the last export of the file, prio two is the path of the last export of any file. I did a quick test and wasn't able to reproduce the bug, so I will need a step-by-step on how to reproduce this in a new GIMP session.

Obviously it's not supposed to work like this. I think it should be (1) I load typewriter.jpg
(2) Save would make typewriter.xcf.gz (3) Save-as would change "typewriter" to some other prefix I chose, e.g. "funky-keys"
(4) "export to" should now say, Export to funky-keys.jpg

"Export to" is a shortcut to export to the original file or the most recently exported file. I don't think it is a good idea to change its path if you save a file because it would switch all the time. You save, it changes, you export, it changes, you save, it changes again. You would not be able to consistently use Ctrl + S for save and Ctrl + E to export.

(5) the export to dialogue should bring up the file chooser in the same directory as funky-keys.xcf.gz but with the new name filled in, and that name should be funky-keys.jpg, because I changed the name. (6) "export..." should bring up the file chooser in the same directory as funky-keys.xcf.gz, again with funky-keys.jpg by default.

First of all, there is no "export to dialoge", I assume those are duplicates of the same point. Why is it wrong to assume that the user wants to export to a file in the vicinity of the original file? And if that is wrong, you correct it, and it will make a better guess the next time. I don't think we should change the default path/name/type priorities in this particular situation.

(7) after saving, there must be visible indication that the image is not changed since export. E.g. the * should go away from the title, or there could be an annotation in the undo history to show the filename, or the status bar could say "exported to funky-keys.jpg in /media/thumbdrive6/typewriters"

The * should definitely go away after you save. It doesn't do that for you? If it doesn't, then that is another bug. What is the step-by-step in a new GIMP session?

(8) if I am saving to a filename other than the CURRENT filename shown in the title bar, and the file exists, I must be warned and asked if I want to overwrite the file.

I assume you meant to write ".. I must be warned and asked if I want to overwrite the file when I do an "Export to"? If that is what you meant, then maybe that is a good idea. Peter, what do you think? If you literally meant what you write then yes it should definitely ask you if you want to overwrite a file that already exists and if it doesn't, then that is a bug. It seems to work for me. What is the step-by-step?

However, a repeated export to the same file, with no intervening "save as" to change the filename, needn't warn me. Or there could be a checkbox, "don't warn again for this filename for this particular image, in this gimp session"

Please let's not have any such insecure message boxes in GIMP. GIMP should be confident in what it is doing.

BR, Martin

Liam wrote:

before I go into what happened specifically here, let me state that there is no way to design this to make everybody happy. for every substantial group that wants their particular use-case to be the natural one, there are several other substantial groups that wants _their_ particular use-case to be the natural one...

so the design sets clear goals (at the top of the spec) and those are designed for. if I can do something in the spec to improve the goals set, then I am happy to change it.

Consider

(1) open typewriter.jpg that came in from my camera (2) do some fun editing
(3) save-as to go to typewriter2.xcf.gz

could have just used Save here, since you had a new, untitled file. now the file in your window _is_ typewriter2.xcf.gz.

(4) now I want to make a jpeg so other programs can use the file, so I can upload it on the Web, etc. Aha! there's File->Export to typewriter.jpg,right there in the file menu. I do this, not noticing that it's using the OLD filename,and the file is overwritten with no confirmation. Because jpeg is lossy, I can't now get back the original (actually it was backed up)

it is ironic that this tripped you up, because we spent soooo much time optimising this for that other substantial group that insists to really under all circumstances export back the xcf they have in their window (it is never a jpg or png...) to the original file.

OK, let's suppose I learned my lesson and change to (4) use file->Export.
GIMP has forgotten my new filename (typewriter2.jpg), and has also forgotten that where opened the file (and saved the xcf.gz), and wants me to put the new jpeg file in ~/Documents.

you can see in the spec that for exporting there are very carefully determined cascades for the directory, filename and file type that fully take into account what you have done before with this xcf you are working on. the two things above are therefore bugs. and the thing below can therefore not happen:

So I do File->save-as, and since that can't save in jpeg, I get out a piece of paper, write down the directory (I can't copy it onto the clipboard because the gtk+ file chooser uses buttons, and dragging doesn't seem to work either, so I write it down. Then I cancel, bring up file->export and navigate, a folder at a time, to that directory.

so let's have a look at this:

I have 100 images to edit, so this isn't really saving me time. Obviously it's not supposed to work like this. I think it should be (1) I load typewriter.jpg

you have an untitled xcf

(2) Save would make typewriter.xcf.gz

Save does default to typewriter.xcf, but we are not going to force you because when you start a new GIMP file with an imported jpg we cannot read your mind what project you are starting and where it should be stored.

(3) Save-as would change "typewriter" to some other prefix I chose, e.g. "funky-keys"

the file in your window is now funky-keys.xcf(.gz)

(4) "export to" should now say, Export to funky-keys.jpg (5) the export to dialogue should bring up the file chooser in the same
directory as funky-keys.xcf.gz but with the new name filled in, and that name should be funky-keys.jpg, because I changed the name.

it was specifically designed for that other substantial group that insists to really under all circumstances export back the xcf they have in their window (it is never a jpg or png...) to the original file. Export is what you are looking for.

(6) "export..." should bring up the file chooser in the same directory as funky-keys.xcf.gz, again with funky-keys.jpg by default.

although there are ten or so other substantial groups that have other priorities, I can tell you that according to the spec under most circumstances this will happen.

(7) after saving, there must be visible indication that the image is not
changed since export. E.g. the * should go away from the title, or there could be an annotation in the undo history to show the filename, or the status bar could say "exported to funky-keys.jpg in /media/thumbdrive6/typewriters"

in your window is an xcf and it can only be saved to xcf. this is the core goal of the spec, making clear that what you have in your window is a GIMP file, always.

if there is anything I can do in the UI to make that clearer, I will do so.

(8) if I am saving to a filename other than the CURRENT filename shown
in the title bar, and the file exists, I must be warned and asked if
I want to overwrite the file. However, a repeated export to the same file, with no intervening "save as" to change the filename, needn't warn me. Or there could be a checkbox, "don't warn again for
this filename for this particular image, in this gimp session"

You have Saving and Exporting mixed up here.

The only thing that can improve things in the right direction is to look at how 'Export to' can be more clear in the menu. 'Export back to foo.jpg' ?

--ps

founder + principal interaction architect man + machine interface works

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

Hi all.

Some random thoughts from me. Not sure if they form a coherent picture though... :)

peter sikking (peter@mmiworks.net) wrote:

[Liam wrote]

Consider

(1) open typewriter.jpg that came in from my camera (2) do some fun editing
(3) save-as to go to typewriter2.xcf.gz (4) now I want to make a jpeg so other programs can use the file, so I can upload it on the Web, etc. Aha! there's File->Export to typewriter.jpg,right there in the file menu. I do this, not noticing that it's using the OLD filename,and the file is overwritten with no confirmation. Because jpeg is lossy, I can't now get back the original (actually it was backed up)

it is ironic that this tripped you up, because we spent soooo much time optimising this for that other substantial group that insists to really under all circumstances export back the xcf they have in their window (it is never a jpg or png...) to the original file.

The spec has the reasoning "A much better reason for optimising are situations where high-end GIMP users have to do some quick touch-ups on graphic files for mates or clients, and send them back."

This is a Workflow, where I don't see a xcf-file (in the file system) involved at all, i.e. the artist imports a PNG, does some touchups, exports back to the same file and quits Gimp/closes the image, not caring about not having saved his work.

Liams workflow had a step in it, where he conciously changed the perceived "identity" of the image he is working on, by *changing* the suggested filename. To me it would be reasonable to assume, that he did this to protect his original file.

(A kind of related irk for me is btw., that an image imported from a flat file format is "Untitled" and has the same naming state as a blank slate created with File->New. It feels like throwing away information. It is a bit unfortunate, that the "Title" is basically the same as the filename, inkluding extensions. If we would change this to use e.g. the basename with stripped extensions it would be natural to have - after importing "typewriter.jpg" - a title of "typewriter", which results in the default suggestion of "typewriter.xcf" for saving and exporting (back) to "typewriter.jpg")

Upon saving as "funky-keys.xcf" - i.e. a conscious change of the title - the default export-filename-suggestion could change to "funky-keys.jpg" (Format derived from the originally imported file).

Note that this does not at all change the workflow in the spec for quick touchups with no concious name changing involved, esp. if not at all saving your work.

Bye,
Simon

Simon wrote:

it is ironic that this tripped you up, because we spent soooo much time optimising this for that other substantial group that insists to really under all circumstances export back the xcf they have in their window (it is never a jpg or png...) to the original file.

The spec has the reasoning "A much better reason for optimising are situations where high-end GIMP users have to do some quick touch-ups on
graphic files for mates or clients, and send them back."

This is a Workflow, where I don't see a xcf-file (in the file system) involved at all,

it is in the main window

i.e. the artist imports a PNG, does some touchups, exports back to the same file and quits Gimp/closes the image, not caring about not having saved his work.

and that is how it works.

Liams workflow had a step in it, where he conciously changed the perceived "identity" of the image he is working on, by *changing* the suggested filename. To me it would be reasonable to assume, that he did
this to protect his original file.

that is too much extrapolation from the use-case. the only thing we can conclude in general from saving a new file is that users want to keep this GIMP composition (that they see in the window) for future use,
and that they gave it a identity. We (traditionally) reflect both.

(A kind of related irk for me is btw., that an image imported from a flat
file format is "Untitled" and has the same naming state as a blank slate
created with File->New. It feels like throwing away information. It is a
bit unfortunate, that the "Title" is basically the same as the filename,
inkluding extensions. If we would change this to use e.g. the basename with stripped extensions it would be natural to have - after importing "typewriter.jpg" - a title of "typewriter", which results in the default
suggestion of "typewriter.xcf" for saving and exporting (back) to "typewriter.jpg")

as you can see in the spec, the information is not thrown away for saving and exporting. the information is in the title:

"Untitled (imported from typewriter.jpg)"

specced but still to be implemented is DRC's excellent contribution to label the first layer where the imported image sits also "typewriter.jpg" instead of Background.

what we really must avoid is the old confusion that users think that what they see in the window is just the jpg. it is not, else there would be no possibility to add a layer, a path, etc.

Upon saving as "funky-keys.xcf" - i.e. a conscious change of the title -
the default export-filename-suggestion could change to "funky- keys.jpg"
(Format derived from the originally imported file).

we can only do no-dialog-save and no-dialog-export to a user-known combination of directory, filename and file type. the cases where this works are in the current spec. the 'Export to' destination is updated after an Export... it is not up to GIMP to provide guesswork export destinations (what directory? of the opened jpg or the save xcf?).

--ps

founder + principal interaction architect man + machine interface works

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

Liam R E Quin (liam@holoweb.net) wrote:

[...] Experienced users are
unlikely to want to overwrite the original jpeg, because they know it loses data.

Well, no. The "Export to " Menupoint is exactly for the usecase that someone opens a jpeg, does some quick adjustments and fully intentionally wants to overwrite the original file, because he does not care about the full blown XCF data.

The point is, that with the semantic change of "Save" to "use XCF always" (which is IMHO a very good thing) you lose this kind of non-xcf-load-edit-save possibility for quick and dirty editing. Which is why the Export to thing got added to accomodate for this.

The problem that arises with this is though, that the user suddenly mentally has to deal with two not-really-but-nearly independant filenames and to predict what a keyboard shortcut will do you have to read the window title.

I think I'd prefer a tighter coupling between the XCF filename and the Export-to filename, i.e. changing the XCF filename also changes the basename of the Export-to-filename.

Bye, Simon

Simon Budig wrote:

Liam R E Quin (liam@holoweb.net) wrote:

[...] Experienced users are
unlikely to want to overwrite the original jpeg, because they know it loses data.

Well, no. The "Export to " Menupoint is exactly for the usecase that someone opens a jpeg, does some quick adjustments and fully intentionally wants to overwrite the original file, because he does not care about the full blown XCF data.

The point is, that with the semantic change of "Save" to "use XCF always" (which is IMHO a very good thing) you lose this kind of non-xcf-load-edit-save possibility for quick and dirty editing. Which is why the Export to thing got added to accomodate for this.

The problem that arises with this is though, that the user suddenly mentally has to deal with two not-really-but-nearly independant filenames and to predict what a keyboard shortcut will do you have to read the window title.

I think I'd prefer a tighter coupling between the XCF filename and the Export-to filename, i.e. changing the XCF filename also changes the basename of the Export-to-filename.

That makes a lot of sense. The coupling should include the full path too with none of the Untitled-1 sillyness. (Untitled should only apply to a newly created image that has not yet been saved.)

Importing /path/foo.png should create an unsaved /path/foo.xcf with that in the title bar.

Subsequent Save as png should automatically set the default file name to /path/foo.png .

If gimp is going to force the user to work in xcf end move into the import export business, this seems to be the way it can be made as transparent and painless as possible.

Such logic should be kept as simple and unconditional as possible. All attempts to do this or that (or something else again) depending on a number of criteria inevitably makes the programs behaviour inconsistent and unpredictable to anyone outside the team who wrote the code.

I have seen this fundemental design error in so much software. Trying to be over helpful and second guess what the user really wants to do in an array of different circumstances ultimately fails because the program does not know what the user wants to de because it's only linked to his mouse, not his brain. Equally but more importantly the user does not know what the program wants to do because he does not know the ins and outs the the double-guessing algo it uses.

Bottom line, trying to be too helpful ends up being unhelpful.

I think that needs to be considered here when prioritising three of four possible policies for where to save/export a file.

regards.

Bye,
Simon

gg (gg@catking.net) wrote:

Subsequent Save as png should automatically set the default file name to /path/foo.png .

*Please* try to be exact in this discussion. You *cannot* "Save as PNG", you can only "Export as PNG". The *only* format you can "Save" to is XCF and its compressed variants.

Thanks, Simon

On 06/10/2009 04:33 PM, Simon Budig wrote:

gg (gg@catking.net) wrote:

Subsequent Save as png should automatically set the default file name to /path/foo.png .

*Please* try to be exact in this discussion. You *cannot* "Save as PNG", you can only "Export as PNG". The *only* format you can "Save" to is XCF and its compressed variants.

Thanks, Simon

I have tried to stay out of this, but I can't resist any longer. It is likely my own ignorance and/or not having seen a previous related discussion, but.....

Why is there such a strong distinction between "Save As" and "Export"?

To the _user_ what benefit is this distinction?

My 2.6.6 (on Ubuntu Linux) does _not_ have an "Export" on the menu that I can find.

If I open a JPG, add a layer to it, and then use the "Save As" menu item to get the "Save As" dialog and if I change the extent to .PNG, I then get a dialog regarding Export. All well and good. But to the _user_ that is just another necessary step in the process of "Saving As" a file to a format that cannot handle whatever features (layer, in this case) are currently in the working (unsaved) file. "Exporting" it is not something that (at least that I can find in my Gimp) the user can do from the menu.

However, I have used a number of other programs where Export is a menu item -- and I have not really understood why that Export was offered separately. In those programs, one could Save As to a few dozen formats, but had to use Export to accomplish a similar goal to a few other formats.

To the _user_, additional "exporting" steps are required, in this case, in the process of doing "Save As". But to speak of "Export" as a distinct task I do not quite understand. Nor do I understand why it seems to be an issue as a distinct task. What am I missing?

(I am not referring to why this discussion has been ongoing, i.e. how it works; I am just wondering about the semantics and trying to better understand what the posters are wishing to accomplish with their choice of words.)

Or is this discussion / plan headed toward adding "Export" as a distinct menu item. But, if so, why? How does that help the user?

My understanding of all uses of "Save As" is: A new file is created that includes any changes made to the old file (within the scope of the capability of the new filetype), and unless that new file specifically overwrites the old file, the old file is closed without saving possible changes that might have been made to the old file.

BTW, that Export dialog has a "Help" button. I think there is a bug or not-yet-implemented feature, because that "Help" button gets an "Eeek!" page on my system:
/usr/share/gimp/2.0/help/en/help-missing.html whereas the "Help" button on the actual "Save As" dialog _does_ get a proper page of help info. Should this be reported on Bugzilla or is it just one of those things still in process?

Jay

Jay Smith (jay@JaySmith.com) wrote:

On 06/10/2009 04:33 PM, Simon Budig wrote:

gg (gg@catking.net) wrote:

Subsequent Save as png should automatically set the default file name to /path/foo.png .

*Please* try to be exact in this discussion. You *cannot* "Save as PNG", you can only "Export as PNG". The *only* format you can "Save" to is XCF and its compressed variants.

Thanks, Simon

I have tried to stay out of this, but I can't resist any longer. It is likely my own ignorance and/or not having seen a previous related discussion, but.....

I'll make it short to not distract from the original point of the discussion, if there is a need to discuss this in more depth, please open a new thread.

Why is there such a strong distinction between "Save As" and "Export"?

To the _user_ what benefit is this distinction?

We want to make it absolutely clear to the user, that with basically all fileformats you lose more or less information. We want the user to make a conscious descision on that.

If some programs have both "Save" and "Export" and offer multiple options in both of them, then hopefully all the options in "Save" can store all the aspects of the document you're working on and load them back properly.

More on the reasoning can be found in the spec: http://gui.gimp.org/index.php/Save_%2B_export_specification

Bye, Simon

On Wednesday, June 10, 2009, 23:01:50, Jay Smith wrote:

However, I have used a number of other programs where Export is a menu item -- and I have not really understood why that Export was offered separately. In those programs, one could Save As to a few dozen formats, but had to use Export to accomplish a similar goal to a few other formats.

In those programs Export is usually used when the output format is significantly different from the program's native format (eg. when you want to create a bitmap from a vector drawing program, or when you create a PDF - in both of these cases, you wouldn't be able to open the resulting file in the original program, and edit it like you can do with the formats that can be saved to; of course, you can edit the bitmaps you "export" in GIMP 2.7, so I find this "feature" annoying).

peter sikking wrote:

what we really must avoid is the old confusion that users think that what they see in the window is just the jpg. it is not, else there would be no possibility to add a layer, a path, etc.

If they've not actually added any of those elements, then it is actually just a jpg - ie. it should be possible to save a file without additional warnings to any format that is capable of representing all actually used elements.

Graeme Gill.

Graeme Gill (graeme2@argyllcms.com) wrote:

peter sikking wrote:

what we really must avoid is the old confusion that users think that what they see in the window is just the jpg. it is not, else there would be no possibility to add a layer, a path, etc.

If they've not actually added any of those elements, then it is actually just a jpg - ie. it should be possible to save a file without additional warnings to any format that is capable of representing all actually used elements.

No it is not.

It is decompressed pixel data. It would be a pure accident if a recompression to JPEG would result in the same file.

The decompressed pixel data lives in a layer object, which has properties like e.g. a name. The layer itself lives in a container object, which also can contain channels and paths. There possibly are attached parasites, containing thumbnail and comment information. A default color profile has been attached if none was specified. Etc. pp.

It just no longer is a jpeg.

Bye, Simon

Simon Budig wrote:

Graeme Gill (graeme2@argyllcms.com) wrote:

If they've not actually added any of those elements, then it is actually just a jpg - ie. it should be possible to save a file without additional warnings to any format that is capable of representing all actually used elements.

No it is not.

It is decompressed pixel data. It would be a pure accident if a recompression to JPEG would result in the same file.

Not at all, if you don't change anything and compress with the same quantization tables, the file will be almost identical.

The decompressed pixel data lives in a layer object, which has properties like e.g. a name. The layer itself lives in a container object, which also can contain channels and paths. There possibly are attached parasites, containing thumbnail and comment information. A default color profile has been attached if none was specified. Etc. pp.

It just no longer is a jpeg.

Right, you've convinced yourself because of your internal storage format that it is somehow different. But if the user hasn't changed anything, then fundamentally it is unchanged (as far as the user is concerned and for all practical purposes), and therefore you are just getting yourself in a knot over purely theoretical issues.

It's not that hard - the internal and native format should (ideally) be a superset of all possible formats that can be read or created. Keep track of which elements are used or created in the process of editing the image, and you can decide whether it's possible to save back to any particular format without significant loss.

Graeme Gill.

Hi,

On Wed, 2009-06-10 at 17:01 -0400, Jay Smith wrote:

BTW, that Export dialog has a "Help" button. I think there is a bug or not-yet-implemented feature, because that "Help" button gets an "Eeek!" page on my system:
/usr/share/gimp/2.0/help/en/help-missing.html whereas the "Help" button on the actual "Save As" dialog _does_ get a proper page of help info. Should this be reported on Bugzilla or is it just one of those things still in process?

That should not be reported on Bugzilla. Instead you should offer your help to the GIMP documentation team and support them to get that section of the user manual written. That is what the help-missing.html asks you to do, right?

Sven

Hi,

On Fri, 2009-06-12 at 10:59 +1000, Graeme Gill wrote:

It's not that hard - the internal and native format should (ideally) be a superset of all possible formats that can be read or created. Keep track of which elements are used or created in the process of editing the image, and you can decide whether it's possible to save back to any particular format without significant loss.

That would require that all file save plug-ins somehow tell the GIMP core what features they support. Of course this would be possible to implement, but it is not trivial and it could not be done in a backward-compatible way. Something to consider for the next generation GIMP plug-in API, but not a helpful suggestion for the current discussion.

Sven

so what happened here?

I have spend the last week and a half laying awake at night what is going on with this topic. I have re-evaluated every fundamental principle that is the basis for the change, looking at "what is it is the other way around for users?" and if that also could solve the 2.6 mess. because let's face it, the 2,6 situation is a mess.

however it is not the fundamental principles that are wrong, but the current execution. I will now outline what has to change, it uses suggestions of Liam, Simon and Alexia, glued into a solid concept again:

- more recognition for non-GIMP images: no longer Untitled in the title bar of the window for imported images or (the interesting case) where a new composition is exported but not yet saved. the name part of the filename is displayed in the titlebar (e.g. "[lawnmower]" for "lawnmower.jpg"), it has to look different than GIMP files, else we have usability accidents there too, hence the brackets.

- filenames are always the first thing in a title, so they show up in the taskbar, etc.

- the '*' is still used for the save-state, but we can show more info after the filename in the title bar of the window: "(imported)", "(overwritten)", "(exported)". "(overwritten)" and "(exported)" are cleared again when a change is made to the composition in the window.

- change to the title of the menu item that does the 'back-sport', for "situations where high-end GIMP users have to do some quick touch-ups on graphic files for mates or clients, and send them back." after a long brainstorm on irc and munching on it for a couple of days more the winner is:

"Overwrite lawnmower.jpg"

where lawnmower.jpg is the imported file. it still shares the position and shortcut (ctrl-E) with the "Export to foo.png" item in the File menu.

- a shorter window of opportunity for back-sport: when a composition is saved or exported to a different file, the Overwrite of the imported file either dimmed or replaced with the 'Export to foo.png' item.

these changes are not in the spec yet, I plan to add them soon.

--ps

founder + principal interaction architect man + machine interface works

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

hi all,

as this issue stays intricate, a brainstormish thought:

clearly, Save must result in an XCF getting written somewhere (unless the operation gets cancelled). This doesn't rule out that e.g. a JPG gets exported in the process.

So in the last resort we could abstract away the export/save distinction by automatically writing a backup XCF, much like an on-disk undo stack which persists across editing sessions. Such a cross-session undo stack will shurely be worth it's price in general; some corner cases have to be solved, though.

Another variant: allow save-as-jpeg and ask for writing a backup XCF upon closing the image.

As anything but save-as-xcf results in a final nag-screen anyway, the user doesn't gain much from learning the export/save distinction. So we can as well sweep that under the table and pretend that save-as-jpeg were safe, up to the point when the image gets closed.

peter sikking schrieb:

however it is not the fundamental principles that are wrong

yes, absolutely. And what we're doing here is trying to cure the symptoms of the deeper problem that is the broken concept of 'Save'. That trojan horse is a gift from today's underpowered desktop environments. ...with greetings from Jef Raskin. More of this rant available upon request ;)

regards, peter

hi,

after some more thinking, here's my reasoning why indeed 'Save' is the problem.

This becomes clear in comparison with a database-driven, version-controlled approach as e.g. sketched in the last mockup of [1]. A Save command is superfluous in this scenario. When an image gets edited, it's reasonable to assume the user wants to keep the changes. Otherwise she can undo, revert (= bulk undo) or simply delete the image. The only IO-commands required here are Import and Export, to exchange images between the world and the database. Easy interface _and_ technically clean, i think.

Now current GIMP already employs sort of a temporary database of version-controlled images: that is the working set of currently opened images. Prior to editing, images are opened (=imported) into the working set. The equivalent for Export is Save-a-Copy.

The major difference from a user's point of view is that the composition explicitely has to be saved to disk, otherwise it gets lost. So obviously the problem must be rooted in having to Save manually, which is a legacy concept from the era of floppy disks [2].

The current spec builds a clean model on top of that legacy Save concept. And the result is not as easy as we all would like it to be. That a lot of effort is required to communicate the model in the UI is probably a sign of that.

In mid-term i see GIMP going the database-driven path anyway [3], but for now we clearly have to support the classic Open/Edit/Save cycle. For that scenario, it seems we can't have both of easy and clean. So i think it's worthwile to reconsider easy-but-dirty models.

greetings, peter

Notes sorted from on-topic to off-topic:

[1] http://gimp-brainstorm.blogspot.com/2009/04/version-control.html

[2] slightly related, i was quite surprised to find that messing with files also builds a good share of the accidental complexities of batch processing. compare: http://gimp-brainstorm.blogspot.com/2009/05/basic-batch-processing.html

[3] the canonical objections are that version control is too expensive for graphical work and that databases lead to application lock-in.

With GEGL under the hood, the first is not valid anymore. In general, it is wasteful to store a second XCF instead of a diff of the GEGL tree. And storing each composition in a self-contained file will face efficiency problems as well: consider a composition created from 5 JPEGs of GPixel size each. Should all the source data be duplicated in the XCF?

Application lock-in is a serious concern, though. I think there's concensus that at desktop level, hierarchical file systems don't serve users well anymore, due to their thousands of multimedia documents. Applications like F-Spot and Rhythmbox maintain their own databases, which leads to lock-in or at best duplicated effort.

So ideally, these databases have to be provided by the desktop environment, and that's the point when GIMP will shurely jump on that train. Anyhow, it is debatable wether a private database for GIMP causes application lock-in any worse than the XCF format already does now.

On Thu, Jun 25, 2009 at 4:55 PM, yahvuu wrote:

In mid-term i see GIMP going the database-driven path anyway [3],

While in the shortterm tools like dropbox get hot :)

Alexandre

hi,

Alexandre Prokoudine schrieb:

On Thu, Jun 25, 2009 at 4:55 PM, yahvuu wrote:

In mid-term i see GIMP going the database-driven path anyway [3],

While in the shortterm tools like dropbox get hot :)

why shure, dropbox is an example of what can be gained on the database-driven path. It's hard/laborious to achieve the same with conventional file systems.

While dropbox seems to focus on sharing/network storage, the desired benefits for GIMP are version control and potentially reliable linking of files together (think of Inkscape SVGs with embedded PNGs)

This doesn't rule out to make parts of such a database public...

greetings, peter

yahvuu wrote:

This becomes clear in comparison with a database-driven, version-controlled approach as e.g. sketched in the last mockup of [1]. A Save command is superfluous in this scenario. When an image gets edited, it's reasonable to assume the user wants to keep the changes. Otherwise she can undo, revert (= bulk undo) or simply delete the image.

While this and the rest of your mail is true and I agree, one could argue that users of a high-end app still want to be in complete control of when an image composition is written to disk for whatever reason. Or perhaps I'm just too backwards... :)

/ Martin

What version of the gimp is this? I don't have any Export menu or Export to option. The only problem I ever have is with exports from multilayer to single layer images: several of the dialogs presented at save seem unnecessary or superfluous.

Mirai Warren wrote:

What version of the gimp is this?

This is the gimp-developer mailing list where GIMP development is discussed. Most of the new features discussed on this list is not in any released version of GIMP yet. You can however always use the latest implemented features by for example compiling GIMP from git: http://git.gnome.org/cgit/gimp/

or finding someone that does regular builds for your OS.

/ Martin

Martin Nordholts wrote:

While this and the rest of your mail is true and I agree, one could argue that users of a high-end app still want to be in complete control of when an image composition is written to disk for whatever reason. Or perhaps I'm just too backwards... :)

Not just high end apps, all apps. Since Open/Edit/Save is the dominant paradigm, any application that works in a different way is going to be the odd one out, and will drive users insane.

Graeme Gill.

Graeme Gill (graeme2@argyllcms.com) wrote (in part) (on 2009-06-25 at 20:34):

Martin Nordholts wrote:

While this and the rest of your mail is true and I agree, one could argue that users of a high-end app still want to be in complete control of when an image composition is written to disk for whatever reason. Or perhaps I'm just too backwards... :)

Not just high end apps, all apps. Since Open/Edit/Save is the dominant paradigm, any application that works in a different way is going to be the odd one out, and will drive users insane.

I'm not a developer nor programmer and applications which use or were changed to use immediate commit to database in a new version caused me some conceptual problems when first encountered. (eg "libraries" in JGSoft's RegexBuddy, database for Website-Watcher, database in PIM InfoQube - aka SQLNotes, captured clips in ClipCache Plus and bookmarks in Firefox 3).

However, once I've convinced myself that the save to database *is* happening and *is* reliable, the switch to the alternate paradigm turns out to be exactly what I want. If I exit having forgotten to save or the application crashes or has to be manually terminated or even it the system blue-screens no fears or worries about what work may have been lost. How could life be any better?

Whether this is possible or feasible with a graphics application like GIMP I leave to better minds than mine.

Alec Burgess wrote:

However, once I've convinced myself that the save to database *is* happening and *is* reliable, the switch to the alternate paradigm turns out to be exactly what I want. If I exit having forgotten to save or the application crashes or has to be manually terminated or even it the system blue-screens no fears or worries about what work may have been lost. How could life be any better?

Whether this is possible or feasible with a graphics application like GIMP I leave to better minds than mine.

That is the issue. In creative applications where most of the time the process is one of exploration from a given start point, having an app. that by default overwrites a previous save point (ie. when it crashes, is killed, exit'ed accidentally, by mistake etc.) is probably not what you want. Many times the process is "I'll open the document, modify it, evaluate, then decide whether to discard/ovewrite the save point/save to something else". Note that the "accidentally loose work" problem is overcomeable in ways that don't involve by default overwriting the start point.

Graeme Gill.

On Fri, Jun 26, 2009 at 4:34 AM, Graeme Gill wrote:

Not just high end apps, all apps. Since Open/Edit/Save is the dominant paradigm, any application that works in a different way is going to be the odd one out, and will drive users insane.

You just never used Palm :)

Somehow users of GRAMPS almost never complain :) (And yes, I happen to be one of them)

Alexandre

On 06/23/2009 09:13 PM, peter sikking wrote:

I have re-evaluated every fundamental principle that is the basis for the change, looking at "what is it is the other way around for users?" and if that also could solve the 2.6 mess. because let's face it, the 2,6 situation is a mess.

however it is not the fundamental principles that are wrong, but the current execution. I will now outline what has to change, it uses suggestions of Liam, Simon and Alexia, glued into a solid concept again:

- no longer Untitled in the title bar of the window for imported images or (the interesting case) where a new composition is exported but not yet saved. the name part of the filename is displayed in the titlebar (e.g. "[lawnmower]" for "lawnmower.jpg")

- the '*' is still used for the save-state, but we can show more info after the filename in the title bar of the window: "(imported)", "(overwritten)", "(exported)".

- change to the title of the menu item that does the 'back-sport', after a long brainstorm on irc and munching on it for a couple of days more the winner is:

"Overwrite lawnmower.jpg"

where lawnmower.jpg is the imported file.

I have implemented these changes now, try it out with latest git master

/ Martin