On Thursday, May 7, 2009, 0:24:12, Martin Nordholts wrote:

I have been working on implementing the Save + export spec [1] for a while. Since it will affect the workflow for basically everyone it would be nice with getting some testing and comments before we finalize

I built a Windows installer with this yesterday, and the comments I got so far are:
- i don't have to try a stupid idea to say that it's a stupid idea - That's bizarre...
- eww so they going to do it after all? - why the hell did they do that

Quoting Martin Nordholts :

I have been working on implementing the Save + export spec [1] for a while. :
:
Comments very much appreciated!

I haven't GITified my development yet and thus have not tried your implementation. If your request for comments is only on the implementation and you are not expecting comments on the export spec itself, I apologize for the following question:

Shouldn't the "Save a copy..." menu item be eliminated since its functionality can be entirely attained by exporting to the GIMP native format?

On Thu, May 7, 2009 at 7:54 AM, Martin Nordholts wrote:

Hi

I have been working on implementing the Save + export spec [1] for a while. Since it will affect the workflow for basically everyone it would be nice with getting some testing and comments before we finalize, merge and push to GNOME master. The patches are attached to the bug report http://bugzilla.gnome.org/show_bug.cgi?id=581655 . Quick-guide to apply and test:

  cd ~/source/gimp
  tar -zxvf save-plus-export-2009-05-06.tar.gz   git checkout -b save-plus-export-2009-05-06 master   git am save-plus-export-2009-05-06/*

this will create and switch to a new branch based on top of your local master branch, and apply the patches to that branch. Then you build and install as usual.

This doesn't seem to work -- patch #0010 fails:

" Applying app: Add an 'export' mode to the file save dialog error: patch failed: app/dialogs/file-save-dialog.c:138 error: app/dialogs/file-save-dialog.c: patch does not apply Patch failed at 0010.
"
The patch appears to be offset by about 10 lines.

I applied it manually, and then ran git-am --skip Patch 0011 applied ok,
Patch 0012 had problems:
"Applying app: Improve save and export error messages error: app/dialogs/file-save-dialog.c: does not match index Patch failed at 0012."

Applied that manually, Patches 013..017 applied OK.
018 says :
"Applying app: Remember last export URI for each image error: app/dialogs/file-save-dialog.c: does not match index error: patch failed: app/file/gimp-file.h:27 error: app/file/gimp-file.h: patch does not apply Patch failed at 0018.
"
Done manually,
019 fails similarly, done manually,
same for 020, 021
022 applied ok.

It's possible that I didn't understand how to 'resolve' a problem ( now I think it is, apply the patch manually, 'git add' the relevant files, and 'git am --resolved')

I'm now trying to build it.. Trying it out..

This works REALLY well! I should also depend on the dirtiness of the image

David

2009/5/7 Jernej Simon?i? :

On Thursday, May 7, 2009, 0:24:12, Martin Nordholts wrote:

I have been working on implementing the Save + export spec [1] for a while. Since it will affect the workflow for basically everyone it would be nice with getting some testing and comments before we finalize

I built a Windows installer with this yesterday, and the comments I got so far are:
- i don't have to try a stupid idea to say that it's a stupid idea - That's bizarre...
- eww so they going to do it after all? - why the hell did they do that

Fortunately, those all sound more like (kneejerk) reactions than comments with any thought to them.
It's good to know what we might need to deal with, though :)

David

Hi,
Just a little reminder about bug 499060 - if someone that can build a the windows installer (err... just noticed Jernej Simon?i? can) could you see if the solution in the bugzilla works http://bugzilla.gnome.org/show_bug.cgi?id=499060

It would be very cool.

Basically, if you installed pygtk from an egg, (or install it silently on windows) then gimp-pyfu doesn't install.

Looking on the web there are a lot of people who have trouble getting gimp+python working, so it would be very cool if you could fix this.

It could make things like this: http://www.gimptalk.com/forum/python-and-gimp-t25587.html Less necessary too.

Cheers,
Stu.

*Hope this isn't too cheeky, but I don't have a gimpwin32/build environment to hand :)

On Thursday, May 7, 2009, 11:47:00, David Gowers wrote:

Fortunately, those all sound more like (kneejerk) reactions than comments with any thought to them.

Show me one person outside GIMP developer community that thinks this is a sane change.

On Thu, 2009-05-07 at 17:08 +0200, Jernej Simon?i? wrote: [...]

Show me one person outside GIMP developer community that thinks this is a sane change.

I don't think many people think it's a sane change, but that's not the right question. The question is, will the resulting interface be good?

People (including me) were very doubtful about the empty image window, and whilst I'm not 100% happy, I'm 99% happy, and it worked out much better than I had feared. So I'm willing to see what happens here.

If you want something different though, you'll need to do more than say the proposed change is insane. You'll need to supply a new proposal that fits in with the vision of GIMP as an xcf editor, or, persuade Peter and others to change the vision slightly.

Best,

Liam

Hi

I have been working on implementing the Save + export spec [1] for a while. Since it will affect the workflow for basically everyone it would be nice with getting some testing and comments before we finalize, merge and push

to

GNOME master.

/ Martin

Hi

My comments and observations: 1. When I try to save and I change extension to (for example) .png, GIMP message appears:
"You can use this dialog to save to the GIMP XCF format. Use File->Export to export to other file formats."
I think it'd be better:
"You can use this dialog to save only to the GIMP XCF format. Use File->Export to export to other file formats."

2. When I open image "foo.png", do some changes and close it, GIMP message says:
"Save the changes to image 'Untitled' before closing? If you don't save the image, changes from the last minute will be lost." There are options:
"Close without Saving", "Cancel", "Save As".

I think it'd be very useful to have option: "Export" and even "Export to foo.png". Obviously in this case GIMP message should be different as well.

3. I have file "foo.png" in "bar" folder, I try to save image "foo" as foo.png in that folder (I changed xcf to png manually) GIMP message appear: "A file named "foo.png" already exists. Do you want to replace it? The file already exists in "bar". Replacing it will overwrite its contents."
Options are: "Cancel" and "Replace". I choose "Replace" and GIMP message says:
"You can use this dialog to save to the GIMP XCF format. Use File->Export to export to other file formats."
I think the second message should appear straight after when I choose "Replace" because first message suggests that I can save "foo.png" anyway, which if not true.

4. In Save Image dialog there's in bottom-right corner button, where you can choose what you see:
"all images", "all files", "gimp XCF Image" Although "all images" is selected, you can see only xcf files.

Best Regards

Michal wrote:

first of all, thanks for trying it out and commenting.

My comments and observations:
1. When I try to save and I change extension to (for example) .png, GIMP
message appears:
"You can use this dialog to save to the GIMP XCF format. Use File-

Export to

export to other file formats."
I think it'd be better:
"You can use this dialog to save only to the GIMP XCF format. Use File->Export to export to other file formats."

you added "only" to the string. I actually find that negative thinking, like we are sorry we are only able to do that for our users.

2. When I open image "foo.png", do some changes and close it, GIMP message
says:
"Save the changes to image 'Untitled' before closing? If you don't save the image, changes from the last minute will be lost."
There are options:
"Close without Saving", "Cancel", "Save As".

I think it'd be very useful to have option: "Export" and even "Export to
foo.png". Obviously in this case GIMP message should be different as well.

This is a point that Martin and I discussed on irc. Here is the main point that the changes are clarifying is:

a file is only safe when it is Saved (in xcf)

this means that export is never the solution to unsaved changes and "Export" and "Export to foo.png" cannot be there in the dialog as ways to resolve the situation.

3. I have file "foo.png" in "bar" folder, I try to save image "foo" as foo.png in that folder (I changed xcf to png manually) GIMP message appear:
"A file named "foo.png" already exists. Do you want to replace it? The file already exists in "bar". Replacing it will overwrite its contents."
Options are: "Cancel" and "Replace". I choose "Replace" and GIMP message
says:
"You can use this dialog to save to the GIMP XCF format. Use File-

Export to

export to other file formats."
I think the second message should appear straight after when I choose "Replace" because first message suggests that I can save "foo.png" anyway,
which if not true.

true, you have found a bug. like you say, the "you can use this dialog..."
message should appear straight away.

4. In Save Image dialog there's in bottom-right corner button, where you can
choose what you see:
"all images", "all files", "gimp XCF Image" Although "all images" is selected, you can see only xcf files.

that looks like another bug to me. it is still useful to see all images (to steal there filenames) in the dialog.

--ps

founder + principal interaction architect man + machine interface works

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

While I haven't tried the new behavior, I would like to be able to see either I have made any changes after the export in the title bar or not. Now it is indicated with a star. I prefer to see it remained.

2. When I open image "foo.png", do some changes and close it, GIMP message
says:
"Save the changes to image 'Untitled' before closing? If you don't save the image, changes from the last minute will be lost."
There are options:
"Close without Saving", "Cancel", "Save As".

I think it'd be very useful to have option: "Export" and even "Export to
foo.png". Obviously in this case GIMP message should be different as well.

This is a point that Martin and I discussed on irc. Here is the main point that the changes are clarifying is:

a file is only safe when it is Saved (in xcf)

this means that export is never the solution to unsaved changes and "Export" and "Export to foo.png" cannot be there in the dialog as ways to resolve the situation.

With respect
Alexander Rabtchevich

Alexander Rabtchevich wrote:

While I haven't tried the new behavior, I would like to be able to see either I have made any changes after the export in the title bar or not. Now it is indicated with a star. I prefer to see it remained.

that would mean we needed two indicators, one that is is saved, and one that it is exported.

but that again would deceive users that export is nearly the same as saving. it is not.

maybe it is better to try it out (for a month) first. because I am sure that the new clarity of when the work you see on your screen is really safe (only in xcf) will change users thinking and behaviour about how to secure their work and when it is a good time to export.

--ps

founder + principal interaction architect man + machine interface works

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

I think you are too biased towards xcf as an everyday storage format. It is not needed very often, at least for now. May I provide my usual workflow?

1. I take pictures in RAW. 2. I convert the pictures I liked in UFRaw and save the result in jpg with maximum quality (1:1:1, floating point, 100%). The tests I made before showed there was no difference with png but the file sizes were less. If a photo requires cropping, resizing, retouching I process it in GIMP. And here is the main point: I save xcf only if I have made complex actions, including layers, which could take too much efforts to repeat. I store intermediate results as invisible layers as possible starting point for future modifications.

Look: the final aim is jpg or any other common format (web, printing, etc.). I only save in xcf if I think it can happen I will need to edit it once more. Storing data in xcf is not so convenient as image viewers do not understand all its nuances. So in most of cases I need 2 things: original untouched RAW as an untouched in any sense source and a result, which is flat image format. This is rather common workflow I guess. If the situation with lossless editing and third-party image viewers changes I think the things with final format will change also. But currently the final format is flat image, not xcf. It is so for printing in a photo lab, web and so on. Storing additional large files or having to convert them to jpg each time they are needed to be handed to someone is not a good thing, at least for a person which has and stores RAWs.

My 2c.

peter sikking wrote:

Alexander Rabtchevich wrote:

While I haven't tried the new behavior, I would like to be able to see either I have made any changes after the export in the title bar or not. Now it is indicated with a star. I prefer to see it remained.

that would mean we needed two indicators, one that is is saved, and one that it is exported.

but that again would deceive users that export is nearly the same as saving. it is not.

maybe it is better to try it out (for a month) first. because I am sure that the new clarity of when the work you see on your screen is really safe (only in xcf) will change users thinking and behaviour about how to secure their work and when it is a good time to export.

With respect
Alexander Rabtchevich

Alexander Rabtchevich wrote:

I think you are too biased towards xcf as an everyday storage format. It is not needed very often, at least for now. May I provide my usual workflow?

I read your workflow and I am confident that when you try it out you will find that we support it well with the Export command and even repeated exporting during your editing session with the 'Export to .jpg' command. The initial critique on the specification made us focus hard to re-evaluate and improve these parts of the spec.

The indicator I cannot do because its price (confusion) is too high.

I simply have to make a trade-off between your kind of use and high-end use that (also for photo) always includes layers and other GIMP specific stuff. The high-end simply has a higher priority, and your kind of use is well supported. This change has been discussed for a long time (like at last year's lgm), but before I came up with the 'Export to ...' solution we would have not dreamed to put this in. Exactly because your kind of secondary workflow would have been badly supported.

--ps

founder + principal interaction architect man + machine interface works

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

Peter, I think you (or me :) ) will be surprised if know the statistics on the percentage of photos which really need complex retouching or complex actions with layers. The most common cases I can give are face retouching, "repairing" of a photo with too high dynamic range or correcting perspective distortion. If a photo is properly exposed, has not excessive noise and is not a portrait of a person you need to improve, there is no need to retouch it after proper RAW conversion.

peter sikking wrote:

I simply have to make a trade-off between your kind of use and high-end use that (also for photo) always includes layers and other GIMP specific stuff. The high-end simply has a higher priority, and your kind of use is well supported.

On Tue, May 12, 2009 at 9:16 PM, Alexander Rabtchevich wrote:

correcting perspective distortion. If a photo is properly exposed, has not excessive noise and is not a portrait of a person you need to improve, there is no need to retouch it after proper RAW conversion.

And therefore there is no need to use GIMP.

Alexandre

On Tue, May 12, 2009 at 6:16 PM, Alexander Rabtchevich wrote:

Peter, I think you (or me :) ) will be surprised if know the statistics on the percentage of photos which really need complex retouching or complex actions with layers. The most common cases I can give are face retouching, "repairing" of a photo with too high dynamic range or correcting perspective distortion. If a photo is properly exposed, has not excessive noise and is not a portrait of a person you need to improve, there is no need to retouch it after proper RAW conversion.

Such adjustments will at some point in the future conceptually be layer-like as well. White balance, exposure control, unsharp-masking and noise reduction, cropping and rotation will be done non-destructively and be possible to tweak later, perhaps even when you re-open your GIMP composition (xcf, xcf2, OpenRaster or whatever,. native GIMP document). If you want to share the resulting image you might as well export it as a JPG, or perhaps even in some other format suited for some particular use.

/Øyvind K.

Pleasant interactive cropping and scaling, required for web are enough reasons. Red eyes reduction sometimes... Why should one use something other if the tool he uses most of the time is convenient and powerful? The above mentioned actions are not too complicated to be reproduced in one minute. Do they worth storing their result in xcf? I think it is so only in the case the format is _well_ understood by third-party applications like image viewers and like.

Alexandre Prokoudine wrote:

correcting perspective distortion. If a photo is properly exposed, has not excessive noise and is not a portrait of a person you need to improve, there is no need to retouch it after proper RAW conversion.

And therefore there is no need to use GIMP.

Alexandre

peter sikking wrote:

Michal wrote:

2. When I open image "foo.png", do some changes and close it, GIMP message
says:
"Save the changes to image 'Untitled' before closing? If you don't save the image, changes from the last minute will be lost."
There are options:
"Close without Saving", "Cancel", "Save As".

I think it'd be very useful to have option: "Export" and even "Export to
foo.png". Obviously in this case GIMP message should be different as well.

This is a point that Martin and I discussed on irc. Here is the main point that the changes are clarifying is:

a file is only safe when it is Saved (in xcf)

this means that export is never the solution to unsaved changes and "Export" and "Export to foo.png" cannot be there in the dialog as ways to resolve the situation.

O.K., but I may not care if file is safe or not. All I want is to have that changed file on my disk. I don't mind if it's saved or exported. Why make things complicated for this kind of users?

Next: It's not clear what will happen to my "foo.png" file after I choose "Save" image as 'Untitled.xcf'. Will my "foo.png" be changed as well? Will my "foo.png" disappear because it's now "safe" as 'Untitled.xcf' and I don't need it any longer?

Maybe it'd be better to completely rearrange that dialog to something like: "If you close the image, changes from last minute will be lost. You can either save image as 'Untilted.xcf' or export it to any other format"
"CLOSE" "CANCEL" "SAVE" "EXPORT"

Best Regards

Michal (mmiicc)

Michal wrote:

This is a point that Martin and I discussed on irc. Here is the main point that the changes are clarifying is:

a file is only safe when it is Saved (in xcf)

this means that export is never the solution to unsaved changes and "Export" and "Export to foo.png" cannot be there in the dialog as ways to resolve the situation.

O.K., but I may not care if file is safe or not. All I want is to have that
changed file on my disk. I don't mind if it's saved or exported. Why make
things complicated for this kind of users?

we currently have a mess and it needed straightening out by a clear separation of save and export. the clear separation is destroyed for users as soon as there is one hint that and export is also save/safe.

Next: It's not clear what will happen to my "foo.png" file after I choose
"Save" image as 'Untitled.xcf'. Will my "foo.png" be changed as well? Will my
"foo.png" disappear because it's now "safe" as 'Untitled.xcf' and I don't need
it any longer?

foo.png was never inside GIMP. it was an xcf that had foo.png as a starting point. we try to reflect this in every way. one way that came up during LGM discussions was that the layer should be always (even for "background") be named after the image that was imported as its starting point. I think we should do that.

to answer your question: foo.png is not touched on disk unless you use "Export to foo.png" in the file menu. easy, no?

Maybe it'd be better to completely rearrange that dialog to something like:
"If you close the image, changes from last minute will be lost. You can either save image as 'Untilted.xcf' or export it to any other format"
"CLOSE" "CANCEL" "SAVE" "EXPORT"

sorry, not a hint...

--ps

founder + principal interaction architect man + machine interface works

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

Hi all,

peter sikking schrieb: > foo.png was never inside GIMP. it was an xcf that had foo.png as a

starting point. we try to reflect this in every way. one way that came up during LGM discussions was that the layer should be always (even for "background") be named after the image that was imported as its starting point. I think we should do that.

that's a really good idea! Regarding export/import, GIMP's document model is much like Inkscape's, with the difference that for the latter, it is immediately understandable why...

Still, i very much hate to send users into one-way streets, and for the open=import case, this is not planned. I wonder if we can't somehow ease the case where export=save? Perhaps via a shortcut like 'export to PNG & close document & discard data'?

When export is just a branch in the workflow and editing continues on the GIMP document in RAM, it might be beneficial to offer one-click Save into a backup-directory without having to choose a filename. Perhaps 'export to PNG & save backup'?

just a rough thought, peter

peter (yahvuu) wrote:

peter sikking schrieb:

foo.png was never inside GIMP. it was an xcf that had foo.png as a starting point. we try to reflect this in every way. one way that came
up during LGM discussions was that the layer should be always (even for "background") be named after the image that was imported as its starting point. I think we should do that.

that's a really good idea! Regarding export/import, GIMP's document model
is much like Inkscape's, with the difference that for the latter, it is
immediately understandable why...

Still, i very much hate to send users into one-way streets, and for the
open=import case, this is not planned.

right, that is an obvious optimisation.

I wonder if we can't somehow
ease the case where export=save? Perhaps via a shortcut like 'export to PNG & close document & discard data'?

When export is just a branch in the workflow and editing continues on the
GIMP document in RAM, it might be beneficial to offer one-click Save into a backup-directory without having to choose a filename. Perhaps 'export to PNG & save backup'?

it is absolutely a design goal that after we have helped users so much to open(/import) foo.png, make some edits and do a 'Export to foo.png' in one click, without dialogs, users must be fully aware that they are throwing away the GIMP document (LGM discussion result: call it a composition) that they used to reach their goal.

we cannot have accident with GIMP compositions not being saved because we offered a too-clever-by-half shortcut.

and to show again our priorities: at LGM Hylke Bons (works on visual design all day long) said: "of course all my work is in project-type files." enough said.

--ps

founder + principal interaction architect man + machine interface works

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

Can one guarantee GIMP compositions will be at least correctly rendered with third-party viewers as image browsing is not in GIMP goals? At least recently xcf has been considered as internal GIMP format. Having thousands files what cannot be easily and quickly viewed and organized is not a good idea IMHO. That will be a reality a user runs into. What is you vision of that problem?

peter sikking wrote:

and to show again our priorities: at LGM Hylke Bons (works on visual design all day long) said: "of course all my work is in project-type files." enough said.

With respect
Alexander Rabtchevich

On Wed, May 13, 2009 at 9:57 AM, Alexander Rabtchevich wrote:

Pleasant interactive cropping

In fact tools like Lightroom or Rawstudio beat GIMP for me when it comes to cropping of photos -- for reasons multiple times explained to GIMP developers.

and scaling, required for web are enough reasons. Red eyes reduction sometimes...

All of the above including cropping can be perfectly done in tools like Rawstudio or F-Spot or digiKam or even in Darktable (which is becoming GEGL based btw). This is why they are (becoming) *workflow* tools.

Alexandre

I suspect thumbnailing will not be enough. Let's see an example of "high end" workflow for photography. One has taken a bunch of RAW images. He has to browse them and compare, delete the bad ones. Then the images need conversion with desired comparing at that stage and the selection goes on... Some of them need postprocessing. And _after_ postprocessing they need scalable up to full-size browsing. Not thumbnails, but full-size preview. No thumbnail would replace large image when selecting which to print, handle, convert to flat format or delete. So the library should be able to make full-size preview.

Martin Nordholts wrote:

Alexander Rabtchevich wrote:

Can one guarantee GIMP compositions will be at least correctly rendered with third-party viewers as image browsing is not in GIMP goals? At least recently xcf has been considered as internal GIMP format. Having thousands files what cannot be easily and quickly viewed and organized is not a good idea IMHO. That will be a reality a user runs into. What is you vision of that problem?

The solution to this is to provide a, probably GIMP maintained, plug-inable component that can do the thumbnailing. Since the current XCF format is tightly coupled with the GIMP internals this is a bit messy but will likely become much easier once we do our rendering with the GEGL library.

With respect
Alexander Rabtchevich

On Sat, May 16, 2009 at 3:38 PM, Martin Nordholts wrote:

One notable change is that Ctrl + E is now bound to File->Export by default instead of View->Shrink Wrap. Hopefully this change will not be too much of a pain. We may need to consider finding a new keyboard shortcut for View->Shrink Wrap.

From what I remember both Inkscape and Scribus use Ctrl+Shift+E for

exporting. Why not be consistent with them and don't have to look for a new shortcut for View->Shrink Wrap? :)

Alexandre

Alexandre wrote:

On Sat, May 16, 2009 at 3:38 PM, Martin Nordholts wrote:

One notable change is that Ctrl + E is now bound to File->Export by default instead of View->Shrink Wrap. Hopefully this change will not be
too much of a pain. We may need to consider finding a new keyboard shortcut for View->Shrink Wrap.

From what I remember both Inkscape and Scribus use Ctrl+Shift+E for

exporting. Why not be consistent with them and don't have to look for a new shortcut for View->Shrink Wrap? :)

there is a couple of things I know for sure:

- both Export and 'Export to ' need a shortcut. - one of these shortcuts needs to be a variant of the other. - 'E' is too good of a shortcut not to use for both of them.

so shrink wrap and fit image in window are looking for new shortcut.

deciding which one should be ctrl-E and which shift-ctrl-E is a rational vs. feeling kind of struggle with many factors.

after checking out Inkscape and Scribus, I think Alexandre just added another valid factor, which means that the balance just tipped the other way:

Export should be shift-ctrl-E

'Export to ' should be ctrl-E

--ps

founder + principal interaction architect man + machine interface works

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