On Sun, Jun 26, 2011 at 4:08 PM, Jeremy Morton wrote:

When I open a non-GIMP format file, like a PNG, by drag-dropping it into GIMP, and then I edit it, I go to export it, by pressing ctrl+E... and nothing happens.  This is because what I actually have to do is select "File | Overwrite (filename.png)".

Wouldn't it be more intuative to behave as if you'd just exported (filename.png), or whatever file you've just imported into GIMP, so that once you've edited it you can just press ctrl+E and easily export it back to its native format?

Intuition is unrelated.

IMO the distiction between exporting and overwriting is quite clear: You can overwrite imported file or export it to save under a different name. GIMP should not try to guess whether you are editing original image or creating a new modification to be saved next to original file.

Alexandre Prokoudine
http://libregraphicsworld.org

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Sun, Jun 26, 2011 at 5:43 PM, Jeremy Morton wrote:

Let's put it another way: I'm the user and I want GIMP to do that.  How can I get it to?

You can't

Alexandre Prokoudine http://libregraphicsworld.org

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Sun, Jun 26, 2011 at 5:49 PM, Jeremy Morton wrote:

It should be possible.

You are in fact suggesting to heavily break use pattern. I don't think developers and UI team will fall for that.

Alexandre Prokoudine http://libregraphicsworld.org

On Sun, Jun 26, 2011 at 6:00 PM, Jeremy Morton wrote:

As far as I can tell the usage pattern has already changed heavily from 2.6.  In 2.6 there was only one save option; now there's a save and export.  You've already changed that significantly.

Yes, and there should be a better reason for going half the way back and introducing a crossbreed of 2.6 and 2.8 than just " it should be possible". I wouldn't really want to rely on arguments like "it doesn't make any sense", but in truth it's exactly what I think. "Overwrite" says exactly what it does. You can assign a shortcut to it.

Alexandre Prokoudine
http://libregraphicsworld.org

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

He's right here =>>

"I'm using the export function. Each time I then press ctrl+E, I'm overwriting that file again and again, without even a prompt. I don't see a meaningful difference between this workflow, and that of importing/editing/exporting."

He doesn't know that Ctrl + Shift + E bring to you the Export Dialog where you can choose your different filename AND / OR different extension.

2011/6/26 Jeremy Morton :

The way I think of the workflow, I'm importing a file, editing it, and exporting it.  Overwriting the file on disk is a mere side-effect of that workflow, and GIMP will prompt me in any case just in case I don't want to overwrite the file.

The thing is, if I go about it a different way and export another file to overwrite that file, I'm using the export function.  Each time I then press ctrl+E, I'm overwriting that file again and again, without even a prompt.  I don't see a meaningful difference between this workflow, and that of importing/editing/exporting.

-- Best regards,
Jeremy Morton (Jez)

On 26/06/2011 15:14, Alexandre Prokoudine wrote:

On Sun, Jun 26, 2011 at 6:00 PM, Jeremy Morton wrote:

As far as I can tell the usage pattern has already changed heavily from 2.6.  In 2.6 there was only one save option; now there's a save and export.  You've already changed that significantly.

Yes, and there should be a better reason for going half the way back and introducing a crossbreed of 2.6 and 2.8 than just " it should be possible". I wouldn't really want to rely on arguments like "it doesn't make any sense", but in truth it's exactly what I think. "Overwrite" says exactly what it does. You can assign a shortcut to it.

Alexandre Prokoudine
http://libregraphicsworld.org
_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On 06/26/2011 09:22 AM, Jeremy Morton wrote:

The thing is, if I go about it a different way and export another file to overwrite that file, I'm using the export function. Each time I then press ctrl+E, I'm overwriting that file again and again, without even a prompt. I don't see a meaningful difference between this workflow, and that of importing/editing/exporting.

Yes, it's going to take some getting used to. However, the HUGE benefit of the new Export functionality is that you will not have to repeatedly specify/confirm the settings of the file format you wish to save to.

In the old version hitting "Save" was very general-purpose. As a result you would have to confirm two or sometimes three (Are you sure you want to overwrite that file?) dialog windows to save a file.

For someone like a web developer/designer, especially working through iterations on one design project, the new approach is a big time-saver.

Now if only the Save for Web dialog would remember the destination folder from save to save....

Jason Simanek

On Sun, Jun 26, 2011 at 6:42 PM, Jeremy Morton wrote:

And I've already gotten used to that; it is logical.  My issue is when you open a non-GIMP format file and then you want to export it back to its original format; I think it makes more sense to just be able to press ctrl+E (with a popup confirming that you want to overwrite) to do that, rather than having a *third* save option, which is File | Overwrite.  I mean, what I am wanting to do is export the image... so ctrl+E makes sense.

So you'd rather email the list than configure shortcuts? :)

Alexandre Prokoudine http://libregraphicsworld.org

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Sun, Jun 26, 2011 at 7:14 PM, Jeremy Morton wrote:

I can't configure the same shortcut for 2 things (file-overwrite and file-export),

Oh, I finally see what you mean :) Sorry :)

Alexandre Prokoudine http://libregraphicsworld.org

2011/6/26 Jeremy Morton :

When I open a non-GIMP format file, like a PNG, by drag-dropping it into GIMP, and then I edit it, I go to export it, by pressing ctrl+E... and nothing happens.  This is because what I actually have to do is select "File | Overwrite (filename.png)".

Wouldn't it be more intuative to behave as if you'd just exported (filename.png), or whatever file you've just imported into GIMP, so that once you've edited it you can just press ctrl+E and easily export it back to its native format?

Yes it would be more intuitive, and that was also the initial design.

The reason it works the way it works today is to avoid data-loss. In GIMP 2.6, the keyboard shortcut Ctrl+E invokes the harmless View -> Shrink Wrap action. In GIMP 2.8, it overwrites an original file. In other words, this sequence of events is harmless in GIMP 2.6:

1. File -> Open file-I-dont-want-to-lose.jpg 2. Make some significant changes
3. Press Ctrl+E

while in GIMP 2.8 the file-I-dont-want-to-lose.jpg would be lost if we made Ctrl+E invoke Overwrite by default and a user, quite reasonable, expects Ctrl+E to still be Shrink Wrap. The idea was that by forcing users to manually assign Ctrl+E to Overwrite, they would confirm that "ok I know Ctrl+E will potentially destory my originals".

That file-overwrite and file-export can't have the same keyboard shortcut is a bug, that is meant to work. Quite an oversight that it doesn't...

Once people have learned that Ctrl+E is export and not Shrink Wrap, we can make Ctrl+E be the default keyboard shortcut for both Overwrite and Export. Until then, I just made a commit so that you can use Alt+F, W instead at least:

commit 9ae0dc034b7791c15479649f71ef4cda8caaf34e Author: Martin Nordholts
Date: Tue Jun 28 08:53:45 2011 +0200

Make 'w' a mnemonic for File -> Overwrite ...

See

[Gimp-developer] Isn't this behaviour unintuative? http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-June/026885.html

Regards, Martin

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

But there was already Ctrl + Shift + E which bring up the dialog for export Ctrl + E was for overwrite without confirm.

Probably the logical order was inverse - many peoples expecting Ctrl + E to bring up the export dialog,

2011/6/28 Martin Nordholts :

2011/6/26 Jeremy Morton :

When I open a non-GIMP format file, like a PNG, by drag-dropping it into GIMP, and then I edit it, I go to export it, by pressing ctrl+E... and nothing happens.  This is because what I actually have to do is select "File | Overwrite (filename.png)".

Wouldn't it be more intuative to behave as if you'd just exported (filename.png), or whatever file you've just imported into GIMP, so that once you've edited it you can just press ctrl+E and easily export it back to its native format?

Yes it would be more intuitive, and that was also the initial design.

The reason it works the way it works today is to avoid data-loss. In GIMP 2.6, the keyboard shortcut Ctrl+E invokes the harmless View -> Shrink Wrap action. In GIMP 2.8, it overwrites an original file. In other words, this sequence of events is harmless in GIMP 2.6:

1. File -> Open file-I-dont-want-to-lose.jpg 2. Make some significant changes
3. Press Ctrl+E

while in GIMP 2.8 the file-I-dont-want-to-lose.jpg would be lost if we made Ctrl+E invoke Overwrite by default and a user, quite reasonable, expects Ctrl+E to still be Shrink Wrap. The idea was that by forcing users to manually assign Ctrl+E to Overwrite, they would confirm that "ok I know Ctrl+E will potentially destory my originals".

That file-overwrite and file-export can't have the same keyboard shortcut is a bug, that is meant to work. Quite an oversight that it doesn't...

Once people have learned that Ctrl+E is export and not Shrink Wrap, we can make Ctrl+E be the default keyboard shortcut for both Overwrite and Export. Until then, I just made a commit so that you can use Alt+F, W instead at least:

commit 9ae0dc034b7791c15479649f71ef4cda8caaf34e Author: Martin Nordholts
Date:   Tue Jun 28 08:53:45 2011 +0200

   Make 'w' a mnemonic for File -> Overwrite ...

   See

     [Gimp-developer] Isn't this behaviour unintuative?      http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-June/026885.html

Regards, Martin

--

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com" _______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Jun 28, 2011, at 11:35, SorinN wrote:

But there was already Ctrl + Shift + E which bring up the dialog for export Ctrl + E was for overwrite without confirm.

Probably the logical order was inverse - many peoples expecting Ctrl + E to bring up the export dialog,

first of all, ctrl-shift-e was chosen because it works like that cross application (inkscape and co).

also think about it: when working on a project (serious work = our priority in design vs. hit and run editing) then there will be in quite a few workflows a lot more ctrl-E (equivalent to ctrl-S) for reviewing, than ctrl-shift-E (equivalent to ctrl-shift-S) for anchoring to another export file(-path/-format).

this is why I am insisting that it is not going to change, in the future.

since the GIMP team (and I as interaction architect particularly) have the duty not to encourage overwriting/destructing the original file by accident, there is no shortcut on overwrite by default. Users can set it by hand, it is their call on the convinience vs. danger balance.

--ps

founder + principal interaction architect man + machine interface works

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

this is why I am insisting that it is not going to change, in the future.

don't get me wrong - as is right now - is very convenient for me and probably for many others, but seems to disturb a part of designers who comes with various backgrounds.

to be clear ..when I see for first time that Ctrl + E just overwrite without confirmation, in the very next second in my mind come that Ctrl + Shift + E should do the job I've asked for. It was true ..and logic. Can't be other - so I can say it's quite intuitive as is.

Btw. I rarely use "File" entry on menu bar. Now I've just discovered there text helpers (Ctrl + E and Shift + Ctrl + E) which indicate the keyboard shortcuts for mentioned functions ;) - funny.

2011/6/28 peter sikking :

On Jun 28, 2011, at 11:35, SorinN wrote:

But there was already Ctrl + Shift + E which bring up the dialog for export Ctrl + E was for overwrite without confirm.

Probably the logical order was inverse - many peoples expecting Ctrl + E to bring up the export dialog,

first of all, ctrl-shift-e was chosen because it works like that cross application (inkscape and co).

also think about it: when working on a project (serious work = our priority in design vs. hit and run editing) then there will be in quite a few workflows a lot more ctrl-E (equivalent to ctrl-S) for reviewing, than ctrl-shift-E (equivalent to ctrl-shift-S) for anchoring to another export file(-path/-format).

this is why I am insisting that it is not going to change, in the future.

since the GIMP team (and I as interaction architect particularly) have the duty not to encourage overwriting/destructing the original file by accident, there is no shortcut on overwrite by default. Users can set it by hand, it is their call on the convinience vs. danger balance.

   --ps

       founder + principal interaction architect            man + machine interface works

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

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

2011/6/30 Jeremy Morton :

My suggestion is an export (to the original file name and file type), but with a 'are you sure you want to overwrite?' dialog before the export happens, with the focus automatically on the cancel so 'enter' will cancel the export.

The popup is good when the user did in fact not want to overwrite the file, whenever the user *do* want to overwrite the file, that popup will be very annoying. Imagine a "are you sure you want to save"-dialog each time you press Ctrl+S.

/ Martin

On Thu, Jun 30, 2011 at 1:34 PM, Jeremy Morton wrote:

My suggestion is that this only happen the *first* time the over presses ctrl-E after importing and editing a file, though.  Subsequent presses once the user has confirmed would overwrite without confirmation.  It's just to avoid overwriting by accident.

I would really hate it if Ctrl-E would overwrite after import even with confirmation. What I personally expect to happen is to have the export dialog pop up just as the save dialog does letting me CHOOSE what I want to do. At this point I can opt to overwrite, by selecting the original file or to save new file next to it. On subequent calls, the export would be silent. This is how save shortcut works. Dialog first, silent on next calls, if the file to be saved to is established. I find it extremely annoying that it does nothing and I need to reach for shift to get even the inital dialog.

--Alexia
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Thu, Jun 30, 2011 at 1:56 PM, Jeremy Morton wrote:

But it's more intuative to assume the imported file's location and format.  If you've imported a file and edited it, it's quite likely you will want to write the changes back out to that file.  If you want to write them somewhere else, it's easy to bring up the advanced export dialog.

This assumption, that the overwrite is desired, is wrong for any photographic workflow. You import your pretty 12Mpix raw or JPG photo, scale and crop and adjust and it would be a tragedy if you destroyed the original at the end. The desired behavior is to keep the type perhaps, but certainly not overwrite.

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Thu, Jun 30, 2011 at 2:08 PM, Jeremy Morton wrote:

So you're assuming that the user is going to 'accidentally' press ctrl-E, then 'accidentally' click on overwrite even though it's not the default selected button?

No, Im telling you that for photographic workflows, desire to overwrite is rather rare. However, users will assume export shortcut to behave analogously to save shortcut, that being, dalog on first evocation, silent save on rest. I know I do. Hence the annoyance with nothing happening.

No, Im telling you that for photographic workflows, desire to overwrite is rather rare

this is true,

can be an unrecoverable mistake, even for one unique picture

but sometime overwriting is convenient and desired

Probably the best way is to have this choice in Preferences

Also from an Usability point of view - probably for the first use of Ctrl+E in a work session - it's ok to present him in pop-up the choices he have - then the user will choose what he want also he will choose his option for the whole session.

So if the user choose "Overwrite without confirmation" - then all that session Ctrl+E will act this way
If he will choose "Bring me the save window every time" - then he will see all export options
If user will choose "Export a Copy" - then for the whole session the file can be saved using incremental sufix

Also as a new option probably is ok to have Save using Preset - that mean a place where user can make reusable patterns with rules for saving files.

Example of a preset for a mass save scenario: 1) preserve the original anyway
2) make an incremental file with PNG extension and the same filename in the folder /home/web/X (with all compression options ..etc) 3) make an image with "sdfasdfasdfasd" name and JPG extension in folder /media/hdd4/Y (with compression options etc). 4) and so ...

2011/6/30 Alexia Death :

On Thu, Jun 30, 2011 at 2:08 PM, Jeremy Morton wrote:

So you're assuming that the user is going to 'accidentally' press ctrl-E, then 'accidentally' click on overwrite even though it's not the default selected button?

No, Im telling you that for photographic workflows, desire to overwrite is rather rare. However, users will assume export shortcut to behave analogously to save shortcut, that being, dalog on first evocation, silent save on rest. I know I do. Hence the annoyance with nothing happening.

--
--Alexia
_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Thu, Jun 30, 2011 at 3:40 PM, Jeremy Morton wrote:

Also I would imagine any sensible user would always save a lossless version of a lossy-format image before editing it and saving.

Why would I save it lossless somewhere BEFORE editing a file Ive imported from a JPG? The loss has already happened, I can always get the exactly same quality for this particular file from the JPG. After editing the only sane format to SAVE to is xcf. Not only is it lossless, you wont lose any of the layers/objects you have made in the process.

 If you're directly
opening a JPEG for editing and then lossy-saving it somewhere else, what are you thinking?!  You're going to keep losing quality.

You dont SAVE to lossy format. You export. Save is to xcf - the only sane starting point for future editing.

--Alexia
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Thu, Jun 30, 2011 at 4:21 PM, Jeremy Morton wrote:

OK, well that's a terminology thing.  I meant export.  Why would you keep exporting it to a JPEG?  I was saying what you're saying; if you're opening/importing a JPEG with the intention of editing it and exporting it, it only makes sense to save a lossless (probably XCF) before you get started.  The criticism of ctrl-E writing to the original file seems to be that you'll lose the quality of the original JPEG, but if you're doing that without having first saved a lossless copy, your workflow is... probably flawed.

It isnt. Sample workflow: Open jpg, Crop, scale, unsharp mask, export for saving to web. I have no reason to save the xcf of neither the source JPG or the resulting web file however I would be extremely distressed If the source JPG got overwritten.

--Alexia
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Jeremy: You have some good points, but also Alexia and the rest have. All this stuff was studied and the consensus was to go ahead with the current implementation.
Of course it's hard to please everyone and this can look bad for some people while looks excellent for others. You already can have a single keystroke overwrite by assigning manually a key combination to that command, so your need is covered. Arguments against unifying export and overwrite are strong, based on preserving the integrity of original files from reckless/distracted users. Overwriting the original file with a modified version is irreversible and it's fine if the proposed workflow protects users from that, leaving the option of overriding that protection only to advanced users who have to assign voluntarily a kestroke for the overwrite command.
Sounds fair to me.

Alexia Death wrote:

I would really hate it if Ctrl-E would overwrite after import even with confirmation.

right. we are never going to mix the 'backward' move of overwriting the original, imported file (destructive move) with the 'forward' move of starting/doing an export.

What I personally expect to happen is to have the export dialog pop up just as the save dialog does letting me CHOOSE what I want to do.

yes, I was thinking the same after reading the input from Jeremy today: what is needed is completing the equivalence between saving and exporting:

if there is no exporting destination and ctrl-E is pressed, show the dialog (as if ctrl-shift-E had been pressed). same for envoking Save on an unsaved file, Save as is actually involved.

I will update the spec now to formalise this.

--ps

founder + principal interaction architect man + machine interface works

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

I wrote:

I will update the spec now to formalise this.

done, and it was not a one-liner.

Martin (prime suspect for implementing the change): please do a careful diff in the wiki to see the changes.

thanks,

--ps

founder + principal interaction architect man + machine interface works

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

2011/6/30 peter sikking :

I wrote:

I will update the spec now to formalise this.

done, and it was not a one-liner.

Martin (prime suspect for implementing the change): please do a careful diff in the wiki to see the changes.

It looks straightforward and I expect to be able to update the code for 2.8.

One gripe: The spec says "give secondary support to workflows where the input and output are the same non-xcf file" and you just made this a bit harder (OK-ing the Export to dialog)

For the record: Would you still want the new approach in the spec if Ctrl+E would previously have been an unused keyboard shortcut?

BR, Martin

Martin wrote:

2011/6/30 peter sikking :

I will update the spec now to formalise this.

done, and it was not a one-liner.

Martin (prime suspect for implementing the change): please do a careful diff in the wiki to see the changes.

It looks straightforward and I expect to be able to update the code for 2.8.

One gripe: The spec says "give secondary support to workflows where the input and output are the same non-xcf file" and you just made this a bit harder (OK-ing the Export to dialog)

no, nothing changed in the Overwrite workflows.

today's changes can be summarised as:

- in the cases where before Export to was insensitive, it is now sensitive and mapped to invoke Export... (the dialog)

- in the cases where Overwrite blocks Export to out of the File menu, the shortcut of Export to is still active and mapped to invoke Export...

everything else works like before

For the record: Would you still want the new approach in the spec if Ctrl+E would previously have been an unused keyboard shortcut?

I noticed the equivalence between the Export and Save departments a long time ago. Today's changes take that one step further.

--ps

founder + principal interaction architect man + machine interface works

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

2011/6/30 peter sikking :

no, nothing changed in the Overwrite workflows.

today's changes can be summarised as:

- in the cases where before Export to was insensitive, it is  now sensitive and mapped to invoke Export... (the dialog)

- in the cases where Overwrite blocks Export to out of the File menu,  the shortcut of Export to is still active and mapped to invoke Export...

everything else works like before

Thanks for the clarifications, I've made this change now:

commit c73bdc097188a926f01062a009f9f22ff32dad4e Author: Martin Nordholts
Date: Thu Jun 30 23:44:50 2011 +0200

app: Make 'Export to' fall back to 'Export...'

Make 'Export to' always sensitive (as long as there is an image at all). And make it fall back to 'Export...' if no export target has been set yet. Note that it is not necessarily visible at all times, sometimes 'Overwrite' shadows it. It shall still be invokable though.

Reference: [Gimp-developer] Isn't this behaviour unintuative? http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-June/026885.html

@Jeremy: Does this work better?

/ Martin

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer