GNOME Bugzilla – Bug 769359
Overwrite shortcut should stay active after an export.
Last modified: 2018-05-24 16:41:42 UTC
Hi, When I open a new .png file the Command-E shortcut is not available via keyboard. I have to first execute "Export As..." and only then the Command-E shows up. This is a major problem when you need to open a lot of files, do a simple change and save&close them: you either have to use the mouse (slow) or go through additional dialogs (slow). I made a video that shows the problem: https://www.youtube.com/watch?v=SekYlC4ON_U Tested with 2.8.14 and 2.8.18 on MacOSX Yosemite. Thanks.
Hello, The menu item is indeed not shown. But doesn't the keyboard shortcut Command-E work anyway (acting as "Export as…", i.e. showing the export dialog)? Here it does work both with GIMP 2.8.x and master, on Linux. Maybe it is a bug on OSX?
If I press Command-E when the shortcut is not shown in the menu item, the program behaves as if I pressed Command-Shift-E, i.e. "Export as..." and shows the dialog to select a filename. Thanks.
However, the whole point is that I want to overwrite the file I loaded (the same way Command-E works) and avoid the dialogs.
> If I press Command-E when the shortcut is not shown in the menu item, the program behaves as if I pressed Command-Shift-E Good. No bug on this side at least. :-) > However, the whole point is that I want to overwrite the file I loaded (the same way Command-E works) and avoid the dialogs You can always create your own shortcut for the "Overwrite" action through the "Edit > Keyboard Shortcuts" menu item. You can even reassign Command-E if you wish. No shortcuts are set by default on this action, on purpose because this is a very dangerous operation (you just overwrite — hence the name — your source image. No warning, no dialog, no nothing). So this is not going to change. But as I said, setting your own shortcut is still always possible for someone inclined and aware of the risk. This way, everyone is happy. Therefore, I guess we should close this as NOTABUG.
You're right, I could configure it to a different key. The problem is that it only works the first time and does not work after I use "Export As" once. So, if I decide to change the filename during my work, I now have to remember that fact and start using Command-E. Keyboard commands should be consistent. If I assign "overwrite file" to something, say Command-R, it should always be available. I understand this helps people who don't use version control for their files, but for us who do, it makes inconsistent interface without any real benefit. However, the existing behavior can remain as is. Just make sure that "Overwrite" shortcut works even after you "Export as". Should I open a new bug report for that?
> The problem is that it only works the first time and does not work after I use "Export As" once. Indeed, just tested. > Keyboard commands should be consistent. If I assign "overwrite file" to something, say Command-R, it should always be available. I agree, I don't think this is good. Well some commands are contextual and it is normal they may not be available in some cases. But for this specific one, I don't think this is a very desirable context change. Mitch > I say the "Overwrite" action stays active even after an export. Of course the "Overwrite" menu item will still disappear, but the action remains active (to be used with shortcut or the action search for instance). I even checked the spec: http://gui.gimp.org/index.php/Save_%2B_export_specification It was actually written nowhere that the "Overwrite" action had to be deactivated after a successful export. If you are ok with this, I can implement this change and push it.
For info, I found the commit a8f552da (bug 646371) where the current issue was created. The person who implemented it was saying: > an image can never be considered both imported and exported at the same time Well I don't really agree and I don't see anywhere in our spec where such a thing is said either. Now I totally understand that we want to advertize the non-destructive path and thus that we hide the "Overwrite" items as soon as someone saves or export. Yet it does not delete the fact that a given file was originally imported. And if someone explicitly set a shortcut on overwrite, this user should still be able to access the overwrite feature (for all other users, this action is virtually non-existent). Also I think that's quite a small change which still goes the desired path of the non-destructive of the source while allowing an alternative (less visible) path for someone who really wants easy destructive path. So it could appease some of the angry people as well. :-)
That "quite small change" would kill something that probably was the result of lenghty discussions on IRC or the mailing list. Also, do you really want to keep around separate import and export filenames? That would be so confusing and lead right to the next bug report.
There was some discussion to allow for multiple exports in a controlled manner - but as a mid-term goal for future GIMP versions. At a minimum, any change done now should be specified in a way similar to the action in the current spec, and not become a "I just committed this change" thing.
(In reply to Michael Natterer from comment #8) > That "quite small change" would kill something that probably was the > result of lenghty discussions on IRC or the mailing list. I don't doubt so. If the spec were up to me, the whole overwrite feature is dangerous and I would not show it *in the menu*. It is there just right next to the export item, ready for a slipping mouse click, and does not ask confirmation on killing the source file. I see the point though as a more hidden hardcode-user feature. (anyway that was a side note). Anyway if that's to exist, I see no reason why it should stop working after an export. It does not really make sense to me, workflow-wise. > Also, do you really want to keep around separate import and export filenames? That would be so confusing and lead right to the next bug report. There are 2 very separate concepts to me. I hardly see how these can lead to a bug. At the opposite, when merging the 2 concepts with a single generically-named variable, I can see better how it can lead to bugs. (In reply to Michael Schumacher from comment #9) > At a minimum, any change done now should be specified in a way similar to the action in the current spec, and not become a "I just committed this change" thing. Of course. I would never commit anything just by my own decision on such a sensitive topic! :P Anyway I'll come to IRC tonight so that we can discuss this. :-)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/940.