Hi Liam

Liam R E Quin wrote:

(1) The file->export dialogue action button says save, not export (sounds really minor but given the save/export changes, can actually be confusing)

Fixed:

commit 5819c3c83a25de4b56360b9d9aa486433c7eaac4 Author: Martin Nordholts
Date: Sun Dec 6 08:58:27 2009 +0100

app: Have an "Export" button, not "Save", in export dialogs

(2) The default save location should not be ~/Documents in the case that a file has been imported - it should default to the directory containing the imported image (see the spec)

Hmm this seems to work for me, what is the exact step-by-step?

(3) in most programs, "save" mirrors "open", and "export" mirrors "import" - if GIMP is erally an XCF editor, "open" should work for .xcf and .xcf.gz files, and File->import should be there for the "rare" 99% case when you want e.g. to touch up a photo, and open a non-xcf file. So, please add file->import, with "import" as the label on the dialogue box. (I think?)

There is a benefit of enforcing a separation between save and export, but I don't see a big benefit of enforcing this kind of separation between open and import. Anyway, this is Peter's domain..

(4) images interfere with each other. E.g. open a colour image, and a grayscale one, and watch the colour one turn to grayscale whenever the grayscae one becomes active... and the grey one goes to RGB seemingly at random, too. This and (2) are making it difficult to use GIMP right now.

I'm not able to reproduce this either, what is the step-by-step?

(8) The curves and levels dialogues look really snazzy in full-screen mode, composited against the layer.

Do you mean 'Colors -> Curves...' and 'Colors -> Levels...' together with 'View -> Fullscreen'? Seems to work fine for me, what is the step-by-step? Are we even running the same version (git master)? :)

Shoeless regards, Martin

On Sat, 2009-12-05 at 17:34 -0500, Liam R E Quin wrote:

(3) in most programs, "save" mirrors "open", and "export" mirrors "import" - if GIMP is erally an XCF editor, "open" should work for .xcf and .xcf.gz files, and File->import should be there for the "rare" 99% case when you want e.g. to touch up a photo, and open a non-xcf file. So, please add file->import, with "import" as the label on the dialogue box. (I think?)

AFAIK the rule in other apps is to have all formats you also can save to in "Open", while "Import" is either for formats you can not save to, an/or to import something that will become just one part of your document (linked or embedded).

Liam wrote:

Some nits ,some -- especially (2) and (4) -- bigger than others...

first thanks for writing this up

(1) The file->export dialogue action button says save, not export (sounds really minor but given the save/export changes, can actually
be confusing)

I see that Martin already repaired this. But the fact that this has not been even specced thoroughly has to do with that we are not following through the complete change down to the export dialogs.

(2) The default save location should not be ~/Documents in the case that
a file has been imported - it should default to the directory containing the imported image (see the spec)

yep bug (the complete precedence algo for Save (as), Export and Save a copy needs verification).

(3) in most programs, "save" mirrors "open", and "export" mirrors "import" - if GIMP is erally an XCF editor, "open" should work for .xcf and .xcf.gz files, and File->import should be there for the "rare" 99% case when you want e.g. to touch up a photo, and open a non-xcf file. So, please add file->import, with "import" as the label on the dialogue box. (I think?)

please hold the sarcasm on 99% import. yes: GIMP is by definition more focussed on working with 'found images' then painting from scratch, but I am sure that you can see the difference between keeping the source code (.xcf) and keeping the executable (.png). since we can only sanely promote working with source code (.xcf), we can assume that when working on something in more than one session, you have to open the source file each session. so that moves the percentage in the direction of 50%.

Now, the spec says we fold open and import into one, and that is because it _is_ more convenient, and there is no confusion price to pay for it. for save + export, there _is_ a confusion price.

(5) I'm not sure that the image title bar is up to spec at all times with respect to imported/exported. At any rate the little language for setting the image title in preferences probably needs to be expanded to include
. the imported image name & (separately) folder . the last exported filename & (separately) folder . the (imported) / (exported) string

how much stuff do you want in a title bar? the title bar actually shows the identity of what's in the window. you know I have bent over backwards to take that identity already from import or export actions before the file is ever saved, so never-saving types like you can distinguish them in the taskbar. the name of the exported to file is in your File menu.

(6) There needs to be indication in the title bar (by default) of when an image has been exported/overwritten, not only immediately, but for the rest of the session, e.g. as *warmsock (*exported)
warmsock (*exported)
warmsock (exported)
*warmsock (exported)
depending on whether the image has been changed since last saved or exported respectively. Not doing this means that people will lose work.

I looked at *starring* the exported with interest, but the main question is "has this state in my image window been exported or not?" and have (exported) or not in the title is a much less subtle indicator of that.

There have already been requests to get rid of the "file has not been saved" message when you close the image, since in most (no all) workflows it's bogus, as the exported image is the final product. So, people get used to ignoring it even when they have not exported an image, and right now you can't esaily tell if you did or not.

please do not project your workflow on the general scheme of things. you know the drill: source file, executable, best practice, safety (losing work). I cannot allow the not-saved warning to be suppressed. exactly for I-almost-never-save-xcf-files type of users, who need it like hell when they do...

(8) The curves and levels dialogues look really snazzy in full-screen mode, composited against the layer. Some problems with this (obviously incomplete) code...
. no title on the doc, so may not always be obvious what it is . no way to drag the dock to a different part of the image . once docks are composited they stay that way, even after you leave full-screen mode. But they are not cmposited _before_ you go into full-screen mode, so I think it's a bug.

this is an experiment of Mitch. properly doing this starts with taking contrast with any kind of image into account. this means forgetting about theme-ing and executing everything in black-to-white contrast. then all the handling you point out...

--ps

founder + principal interaction architect man + machine interface works

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

Liam R E Quin wrote:

Some nits ,some -- especially (2) and (4) -- bigger than others...

(1) The file->export dialogue action button says save, not export (sounds really minor but given the save/export changes, can actually be confusing)

(2) The default save location should not be ~/Documents in the case that a file has been imported - it should default to the directory containing the imported image (see the spec)

(3) in most programs, "save" mirrors "open", and "export" mirrors "import" - if GIMP is erally an XCF editor, "open" should work for .xcf and .xcf.gz files, and File->import should be there for the "rare" 99% case when you want e.g. to touch up a photo, and open a non-xcf file. So, please add file->import, with "import" as the label on the dialogue box. (I think?)

(4) images interfere with each other. E.g. open a colour image, and a grayscale one, and watch the colour one turn to grayscale whenever the grayscae one becomes active... and the grey one goes to RGB seemingly at random, too. This and (2) are making it difficult to use GIMP right now.

(5) I'm not sure that the image title bar is up to spec at all times with respect to imported/exported. At any rate the little language for setting the image title in preferences probably needs to be expanded to include
. the imported image name & (separately) folder . the last exported filename & (separately) folder . the (imported) / (exported) string

(6) There needs to be indication in the title bar (by default) of when an image has been exported/overwritten, not only immediately, but for the rest of the session, e.g. as *warmsock (*exported)
warmsock (*exported)
warmsock (exported)
*warmsock (exported)
depending on whether the image has been changed since last saved or exported respectively. Not doing this means that people will lose work. There have already been requests to get rid of the "file has not been saved" message when you close the image, since in most (no all) workflows it's bogus, as the exported image is the final product. So, people get used to ignoring it even when they have not exported an image, and right now you can't esaily tell if you did or not.

(7) Martin is not allowed to wear shoes until (2) and (4) are fixed!

(8) The curves and levels dialogues look really snazzy in full-screen mode, composited against the layer. Some problems with this (obviously incomplete) code...
. no title on the doc, so may not always be obvious what it is . no way to drag the dock to a different part of the image . once docks are composited they stay that way, even after you leave full-screen mode. But they are not cmposited _before_ you go into full-screen mode, so I think it's a bug.

I can file bugzilla entries for these but probably not for a few days.

Liam

Liam R E Quin wrote:

(1) File->New, make an RGB image, e.g. 377x233px in size. paint a smiling face in red.

(2) File->New, choose Advanced Options and make a grayscale image (I made mine 377x233px).

(3) Notice how the smile in the first image is now gray - you can make the first image RGB again by going to it and hitting undo, but as soon as you go back to the 2nd image, the 1st image goes grayscale again.

I am still not able to reproduce this, following the step-by-step exactly, except I used a different image size. I cleaned my GIMP2_DIRECTORY first. It is weird that your default size is 377x233 since that is not the default size in git master, you must have mixed the versions somehow. In git master the default size is 610x377 (which is what I used)

/ Martin

Martin Nordholts wrote:

Liam R E Quin wrote:

(1) File->New, make an RGB image, e.g. 377x233px in size. paint a smiling face in red.

(2) File->New, choose Advanced Options and make a grayscale image (I made mine 377x233px).

(3) Notice how the smile in the first image is now gray - you can make the first image RGB again by going to it and hitting undo, but as soon as you go back to the 2nd image, the 1st image goes grayscale again.

i can confirm, with default image size 610x377, gtk 2.18.4
glib 2.22.3
and yesterday's git master

regards, yahvuu

yahvuu wrote:

Martin Nordholts wrote:

Liam R E Quin wrote:

(1) File->New, make an RGB image, e.g. 377x233px in size. paint a smiling face in red.

(2) File->New, choose Advanced Options and make a grayscale image (I made mine 377x233px).

(3) Notice how the smile in the first image is now gray - you can make the first image RGB again by going to it and hitting undo, but as soon as you go back to the 2nd image, the 1st image goes grayscale again.

i can confirm, with default image size 610x377, gtk 2.18.4
glib 2.22.3
and yesterday's git master

Was this with a clean GIMP2_DIRECTORY? If not, could you rename it and see if you can reproduce it with a clean GIMP2_DIRECTORY?

/ Martin

Martin Nordholts wrote:

yahvuu wrote:

Martin Nordholts wrote:

Liam R E Quin wrote:

(1) File->New, make an RGB image, e.g. 377x233px in size. paint a smiling face in red.

(2) File->New, choose Advanced Options and make a grayscale image (I made mine 377x233px).

(3) Notice how the smile in the first image is now gray - you can make the first image RGB again by going to it and hitting undo, but as soon as you go back to the 2nd image, the 1st image goes grayscale again.

i can confirm, with default image size 610x377, gtk 2.18.4
glib 2.22.3
and yesterday's git master

Was this with a clean GIMP2_DIRECTORY? If not, could you rename it and see if you can reproduce it with a clean GIMP2_DIRECTORY?

doesn't make a difference (i used export GIMP2_DIRECTORY=/some/new/empty/dir)