Yes, you can add such a shortcut, please go to:

Edit / Keyboard shortcuts ...

There you see the entry

File ...
Overwrite: Disabled

Just change that to a shortcut you like.

Cheers Karl-Heinz

On Thu, 31 Oct 2013 10:28:00 +0530 Ramkumar Ramachandra wrote:

Sorry, I didn't notice the "File > Overwrite " menu option.

Perhaps a keyboard shortcut for the same would be nice.

On 31 October 2013 05:36, Karl-Heinz Zimmer wrote:

Yes, you can add such a shortcut, please go to:

Edit / Keyboard shortcuts ...

Just a somewhat unrelated notice - as I consider this one of GIMP's most important features:
in GIMP you don't have to go to "Edit->Preferences->Interface->Edit Keyboard Shortcuts, navigate in a
separate structure to your feature, and then pick a keyboard shortcut. That is there, and works - but what is cool is the Dynamic Keyboard Shortcuts feature - enable it once in edit->preferences->interfaces -
and never step out of your workflow to assign a shortcut again: Just pick a shortcut when you are about to use a feature, on the very same menu you use all the time.

(it doesn't warn you if you overwrite a shortcut - but then, you can simply restore any accidentaly changed shortcut just as easily)

js ->

Ramkumar,

However,
the process for overwriting the PNG image is too complicated; export (Ctrl+E), overwrite file: , then close (Ctrl+W), and close without saving: . What can we do to make this process simpler?

this part got me thinking-checking-planning.

what we were missing was a quick succession of ctrl shortcuts (cmd on mac) that close unsaved images.

I worked on it with mitch and it is now in git.

so now everyone can press ctrl-W to close a document, keep the finger on the ctrl and press ctrl-D in the dialog to Discard changes.

- this is slightly unusual in GNOME (if not illegal, but I did it for you, girls and guys) so there is a hint in the dialog - yes, also works for Quit and Close all - yes, mitch is back-porting it to 2.8, see next release

try it when you get your hands on it.

Sorry, I didn't notice the "File > Overwrite " menu option. Perhaps a keyboard shortcut for the same would be nice.

I thought about that for a long time when I wrote the spec.

I did not put a shortcut by default for 2 reasons:

- for the primary way of working (with XCF source files), overwriting imported images (by pressing the shortcut) by accident would be an unfortunate disaster.

- I wanted to use the inertia of having to do the effort of setting your own shortcut to make you think: if really, really overwrite _is_ your primary way of working and important enough to set it.

--ps

founder + principal interaction architect man + machine interface works

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

peter sikking writes:

what we were missing was a quick succession of ctrl shortcuts (cmd on mac) that close unsaved images.

I worked on it with mitch and it is now in git.

so now everyone can press ctrl-W to close a document, keep the finger on the ctrl and press ctrl-D in the dialog to Discard changes.

[ ... ]

- yes, also works for Quit and Close all - yes, mitch is back-porting it to 2.8, see next release

Nice! I've lost work a couple of times with the new model, and the Quit dialog solves that problem.

It took me a few minutes to learn how to read it -- it says

[filename.png](imported)-N

if I've modified the image and never exported;

[filename.png](overwritten)-N

if I've exported in the past but not since the last change; and

[filename.png](overwritten)-N Exported to /path/to/filename.png

if it's safe and has been exported since the last change. So it looks like the important thing is whether the extra "Exported to..." line is there. It's great to have that information.

Sorry, I didn't notice the "File > Overwrite " menu option. Perhaps a keyboard shortcut for the same would be nice.

I thought about that for a long time when I wrote the spec.

[ ... ]

- I wanted to use the inertia of having to do the effort of setting your own shortcut to make you think: if really, really overwrite _is_ your primary way of working and important enough to set it.

I've found that the new model makes me stop and think every time I save or export anything. For one thing, I'm still confused about the difference between Export... and Export to -- they seem to do the same thing even though one has a ... and the other doesn't, they have different shortcuts, and one of them isn't always available. And I can never remember in any given session which images can use Overwrite versus which ones need an Export... or Export to, so I no longer trust any save/export shortcut to be the right one, and almost always end up going to the menus instead.

A shortcut for Overwrite would just add the uncertainty of "What if this image doesn't have a file associated with it yet?" -- in which case Overwrite silently does nothing, and you might think you've exported when you really haven't, and lose your work.

Anyway, the new Quit dialog will help in guarding against data loss from export mistakes like that. So thanks!

...Akkana

Date: Fri, 8 Nov 2013 20:15:23 -0800 From: akkana@shallowsky.com
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Quick-edit workflow

I've found that the new model makes me stop and think every time I save or export anything. For one thing, I'm still confused about the difference between Export... and Export to -- they seem to do the same thing even though one has a ... and the other doesn't, they have different shortcuts, and one of them isn't always available. And I can never remember in any given session which images can use Overwrite versus which ones need an Export... or Export to, so I no longer trust any save/export shortcut to be the right one, and almost always end up going to the menus instead.

It's just like the difference between "Save" and "Save As" in that, during the same session, "Export" uses the settings from the previous export (if any) while "Export to..." always prompts for a filename. Of course, if you don't export very often then the difference is moot because every export happens during a different session.

And similar to you, one thing *I* don't get is why "Export" and "Overwrite" need to be separate commands.

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

Richard Gitschlag (strata_ranger@hotmail.com) wrote:

And similar to you, one thing *I* don't get is why "Export" and "Overwrite" need to be separate commands.

Because without this distinction you'd accidentially overwrite your precious orignal file after accidentially doing an "Export" instead of an "Export To".

Bye,
Simon

simon@budig.de              http://simon.budig.de/

guys + girls,

it is a tricky thing, this overwrite vs. export.

there is a difference, overwrite is for working backward as I called it: doing some work on a non-gimp file and feeding this directly back to it. it is labelled brutally and frankly, with intent. export is for working forward, towards a new result.

but as Richard comments, the difference is not that big. this is what I exploited in the design for repurposing the Export-to item for Overwrite.

of course one can use Export... to set up to write over one of the source files of the composition one is working on.

thus exporting is the general game, with one special case built in: hardwiring the initiating source file as export target and giving this a fearsome name (beware: burning bridges)

Yes, Export-to and Export... mirror images of Save and Save-as...

I think I can see what Akkana means: when there is no export target, the menu items are Export to and Export... that is not ideal. and its clear that it irritates people.

note that the export-to item cannot be grayed out in this case. ctrl-E just has to work (leading to an Export..., yes, just as the first Save is a Save As...)

reviewing the situation, I see that the straightforward solution is to relabel

Export... -> Export As... (in all states)

Export to -> Export (when no export target)

you can see that this achieves perfect mirroring of Save and Save As...

Export to foo.xyz and Overwrite foo.xyz stay as-is, they work well with Export As...

(just in case you wonder, yes I am giving up on something by doing this: in so many other application the label on the export menu item is Export... )

--ps

founder + principal interaction architect man + machine interface works

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

From: peter@mmiworks.net
Date: Sun, 10 Nov 2013 02:25:47 +0100 To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Quick-edit workflow

I think I can see what Akkana means: when there is no export target, the menu items are Export to and Export... that is not ideal. and its clear that it irritates people.

note that the export-to item cannot be grayed out in this case. ctrl-E just has to work (leading to an Export..., yes, just as the first Save is a Save As...)

reviewing the situation, I see that the straightforward solution is to relabel

Export... -> Export As... (in all states)

Export to -> Export (when no export target)

you can see that this achieves perfect mirroring of Save and Save As...

Export to foo.xyz and Overwrite foo.xyz stay as-is, they work well with Export As...

(just in case you wonder, yes I am giving up on something by doing this: in so many other application the label on the export menu item is Export... )

--ps

founder + principal interaction architect man + machine interface works

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

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

I definitely agree that the labelling of the Export/Export To commands should completely mirror the labelling of "Save/Save As" commands.

PS: Can we get some accelerator keys put on those menu labels sometime?

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

Richard Gitschlag wrote:

PS: Can we get some accelerator keys put on those menu labels sometime?

apart from Overwrite (by design), where are you missing one?

--ps

founder + principal interaction architect man + machine interface works

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

Hi,

On Sun, Nov 10, 2013 at 2:25 PM, peter sikking wrote:

guys + girls,

it is a tricky thing, this overwrite vs. export.

there is a difference, overwrite is for working ‘backward’ as I called it: doing some work on a non-gimp file and feeding this directly back to it. it is labelled brutally and frankly, with intent. export is for working ‘forward’, towards a new result.

but as Richard comments, the difference is not that big. this is what I exploited in the design for repurposing the Export-to item for Overwrite.

of course one can use Export... to set up to write over one of the source files of the composition one is working on.

thus exporting is the general game, with one special case built in: hardwiring the initiating source file as export target and giving this a fearsome name (beware: burning bridges)

Yes, Export-to and Export... mirror images of Save and Save-as...

I think I can see what Akkana means: when there is no export target, the menu items are “Export to” and “Export...” that is not ideal. and it’s clear that it irritates people.

note that the export-to item cannot be grayed out in this case. ctrl-E just has to work (leading to an Export..., yes, just as the first Save is a Save As...)

Just checking master, currently when "overwrite" is shown, export-to is not grayed out but it is invisible. That means that it is active and can be run if you know the shortcut, but you can't export from the menu (for people who don't know shortcuts, new or casual users, etc.). Is it intended? I feel like this is a mistake and that "Export To" should always show up in the menu.
I could easily fix this.

reviewing the situation, I see that the straightforward solution is to relabel

Export... -> Export As... (in all states)

“Export to” -> Export (when no export target)

I like the change. When there is an export target, should it become "Export As somefile.png"?

Jehan

you can see that this achieves perfect mirroring of Save and Save As...

“Export to foo.xyz” and “Overwrite foo.xyz” stay as-is, they work well with Export As...

(just in case you wonder, yes I am giving up on something by doing this: in so many other application the label on the export menu item is Export... )

--ps

founder + principal interaction architect man + machine interface works

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

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hi,

On Wed, Nov 13, 2013 at 1:45 PM, Jehan Pagès wrote:

Hi,

On Sun, Nov 10, 2013 at 2:25 PM, peter sikking wrote:

guys + girls,

it is a tricky thing, this overwrite vs. export.

there is a difference, overwrite is for working ‘backward’ as I called it: doing some work on a non-gimp file and feeding this directly back to it. it is labelled brutally and frankly, with intent. export is for working ‘forward’, towards a new result.

but as Richard comments, the difference is not that big. this is what I exploited in the design for repurposing the Export-to item for Overwrite.

of course one can use Export... to set up to write over one of the source files of the composition one is working on.

thus exporting is the general game, with one special case built in: hardwiring the initiating source file as export target and giving this a fearsome name (beware: burning bridges)

Yes, Export-to and Export... mirror images of Save and Save-as...

I think I can see what Akkana means: when there is no export target, the menu items are “Export to” and “Export...” that is not ideal. and it’s clear that it irritates people.

note that the export-to item cannot be grayed out in this case. ctrl-E just has to work (leading to an Export..., yes, just as the first Save is a Save As...)

Just checking master, currently when "overwrite" is shown, export-to is not grayed out but it is invisible. That means that it is active and can be run if you know the shortcut, but you can't export from the menu (for people who don't know shortcuts, new or casual users, etc.). Is it intended? I feel like this is a mistake and that "Export To" should always show up in the menu.
I could easily fix this.

reviewing the situation, I see that the straightforward solution is to relabel

Export... -> Export As... (in all states)

“Export to” -> Export (when no export target)

I like the change. When there is an export target, should it become "Export As somefile.png"?

In any case, I have written a patch here: https://bugzilla.gnome.org/show_bug.cgi?id=712192

I guess you can tell if that's good for you, so that it can be committed. :-)

Jehan

Jehan

you can see that this achieves perfect mirroring of Save and Save As...

“Export to foo.xyz” and “Overwrite foo.xyz” stay as-is, they work well with Export As...

(just in case you wonder, yes I am giving up on something by doing this: in so many other application the label on the export menu item is Export... )

--ps

founder + principal interaction architect man + machine interface works

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

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Jehan Pagès writes:

Just checking master, currently when "overwrite" is shown, export-to is not grayed out but it is invisible. That means that it is active and can be run if you know the shortcut, but you can't export from the menu (for people who don't know shortcuts, new or casual users, etc.).

It's definitely useful to have it available via the shortcut (now that I'm clear on what it does :-) -- I'd use it in preference to Overwrite since it means I only have to remember that one shortcut (plus Ctrl-S, of course).

And thanks, Peter, for the name change! These:

Export... -> Export As... (in all states)

“Export to” -> Export (when no export target)

do seem clearer since they're more similar to Save and Save as...

...Akkana

Jehan wrote:

Just checking master, currently when "overwrite" is shown, export-to is not grayed out but it is invisible. That means that it is active and can be run if you know the shortcut, but you can't export from the menu (for people who don't know shortcuts, new or casual users, etc.). Is it intended? I feel like this is a mistake and that "Export To" should always show up in the menu.
I could easily fix this.

yes this is intentional. the spec says:

The shortcut for the Export menu item shall remain active and map to invoking the Export As command, sneaky, but true.

I have done this so that users who press ctrl-E by habit are not stopped by nothing happening. Users who browse the menu see Export As... (the new label) and pick that.

nobody gets hurt. things work as expected. sneaky, but true.

In any case, I have written a patch here: https://bugzilla.gnome.org/show_bug.cgi?id=712192

I guess you can tell if that's good for you

Sorry Jehan, no. you change too much and I must say, with devastating effect.

first of all I did my job and updated the spec:

checked 98 occurrences of export (twice) and updated to the new situation.

in a nutshell, all it is is a string change.

Export... -> Export As...

(no other changes to this menu item or the code behind it.

Export to -> Export (when no export target)

(this is the menu item where Export to foo.xyz and Overwrite foo.xyz are swapped in as appropriate)

do not touch the Save menu items, they work fine, as-is, since 1984. Save is for the main window content and the name of that is in the title bar of that main window.

and that is it.

--ps

founder + principal interaction architect man + machine interface works

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

Hi,

On Wed, Nov 13, 2013 at 11:49 PM, peter sikking wrote:

Jehan wrote:

Just checking master, currently when "overwrite" is shown, export-to is not grayed out but it is invisible. That means that it is active and can be run if you know the shortcut, but you can't export from the menu (for people who don't know shortcuts, new or casual users, etc.). Is it intended? I feel like this is a mistake and that "Export To" should always show up in the menu.
I could easily fix this.

yes this is intentional. the spec says:

‘The shortcut for the Export menu item shall remain active and map to invoking the Export As… command, sneaky, but true.’

I have done this so that users who press ctrl-E by habit are not stopped by nothing happening. Users who browse the menu see Export As... (the new label) and pick that.

nobody gets hurt. things work as expected. sneaky, but true.

In any case, I have written a patch here: https://bugzilla.gnome.org/show_bug.cgi?id=712192

I guess you can tell if that's good for you

Sorry Jehan, no. you change too much and I must say, with devastating effect.

first of all I did my job and updated the spec:

checked 98 occurrences of “export” (twice) and updated to the new situation.

in a nutshell, all it is is a string change.

Export... -> Export As...

(no other changes to this menu item or the code behind it.

“Export to” -> Export (when no export target)

(this is the menu item where “Export to foo.xyz” and “Overwrite foo.xyz” are swapped in as appropriate)

do not touch the Save menu items, they work fine, as-is, since 1984. Save is for the main window content and the name of that is in the title bar of that main window.

and that is it.

Ok. I'll simplify the patch.

Should I change the action's names to follow their label? In particular "Export" would correspond to "file-export" and "Export As..." corresponds to "file-export-as" (otherwise we would end up in the strange situation where "Export" "file-export-to" and "Export As..." "file-export").
Or you care only about UI, not action names, and I should ask Mitch for this? Thanks.

Jehan

--ps

founder + principal interaction architect man + machine interface works

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

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Jehan wrote:

Should I change the action's names to follow their label? In particular "Export" would correspond to "file-export" and "Export As..." corresponds to "file-export-as" (otherwise we would end up in the strange situation where "Export" "file-export-to" and "Export As..." "file-export").

I think it is better that the action names migrate with it.

but better ask mitch what the rules are for changing this.

--ps

founder + principal interaction architect man + machine interface works

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