keybindings
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| keybindings | Liam R E Quin | 26 Jul 04:15 |
| keybindings | peter sikking | 26 Jul 13:19 |
| keybindings | Liam R E Quin | 26 Jul 18:49 |
keybindings
I got back from vacation in the UK (yay no mosquitoes) and tried git head gimp today.
First, a BIG thank you to Peter and others: the new menu item "overwrite" is much clearer.
I do still have a problem in several gnomish scenarios, but things are indeed getting better.
If I use the file manager and drag a file to gimp, or if I use the image thumbnail browser (e.g. gthumb, but others do this too) and say, "open in gimp", then gimp now imports my original jpeg file (say). And a keystroke that I use literally hundreds of times in any one day, will silently, without any warning, overwrite that file -- control-E and control-shift-E (fit window to image, fit window to image, respectively).
It's not that there's a keystroke to save the file with lossy compression: control-S has always done that. It's that the new keystroke was previously used for a frequent and non-destructive operation, and there's no prompting.
In some workflows I can make copies of files first, so possibly an option to entirely disable drag and drop, and the gimp-remote stuff, would help, but that's more draconian than I'd like!
So how about
(1) no default keybinding for "overwrite precious file" at all.
(2) if we can't revert the window bindings (^e and ^E), at least
make show/hide rulers (^R) work again, and (2b) do NOT
have a keyboard shortcut that silently overwrites a file other
than the one you are editing.
(3) there should be a big warning when you use this "export to" thing.
(4) if you use save-as, the default export (not "overwrite, I don't
care about that menu item right now,but export...) filenme doesn't
change, and it obviously should. This is just a bug.
Right now it's just about impossible to move between gimp 2.6 and 2.7 without losing work, and the migration path is *really* scary. But it's improving, I have good hope ;-)
Thanks,
Liam
keybindings
Liam wrote:
First, a BIG thank you to Peter and others: the new menu item "overwrite" is much clearer.
I do still have a problem in several gnomish scenarios, but things are indeed getting better.
If I use the file manager and drag a file to gimp, or if I use the image thumbnail browser (e.g. gthumb, but others do this too) and say, "open in gimp", then gimp now imports my original jpeg file (say). And a keystroke that I use literally hundreds of times in any one day, will silently, without any warning, overwrite that file -- control-E and control-shift-E (fit window to image, fit window to image, respectively).
without warning? spec says that lossy format export will always show one combined export options dialog:
So how about
(1) no default keybinding for "overwrite precious file" at all.
this is the best solution. When the menu item is "Overwrite foo.jpg" there is no shortcut key (by default, users can change this) and the process of invoking it becomes deliberate and visible, via the File menu.
The other use of the menu item, "Export to foo.jpg" will keep the ctrl-E shortcut.
and the double binding of ctrl(-shift)-R, that was a mistake and will be corrected.
thanks for pointing out the concept bugs,
--ps
founder + principal interaction architect man + machine interface works
http://mmiworks.net/blog : on interaction architecture
keybindings
On Sun, 2009-07-26 at 13:19 +0200, peter sikking wrote:
(1) no default keybinding for "overwrite precious file" at all.
this is the best solution. When the menu item is "Overwrite foo.jpg" there is no shortcut key
(this will be a change to the git version)
The other use of the menu item, "Export to foo.jpg" will keep the ctrl-E shortcut.
If that's after I've already exported, I think it's fine, because it's no longer the "master" file.
thanks for pointing out the concept bugs,
Thanks for listening! :)
Liam
