Redo shortcut
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.
| Redo shortcut | Phil Harper | 26 Sep 21:33 |
| Redo shortcut | Guillermo S. Romero / Familia Romero | 26 Sep 22:26 |
| Ooops, error (Re: Redo shortcut) | Guillermo S. Romero / Familia Romero | 26 Sep 22:36 |
| Redo shortcut | Tom Mraz | 26 Sep 23:54 |
| Redo shortcut | Øyvind Kolås | 28 Sep 16:04 |
| Redo shortcut | David Neary | 01 Oct 08:52 |
| Redo shortcut | Guillermo S. Romero / Familia Romero | 01 Oct 17:32 |
| Redo shortcut | Raphaël Quinet | 01 Oct 18:25 |
| Redo shortcut | Sven Neumann | 01 Oct 19:38 |
Redo shortcut
From: Tom Mraz
To: Gimp Developer List
CC: usability@lists.gnome.org
Subject: Re: [Gimp-developer] Redo shortcut Date: Thu, 25 Sep 2003 20:18:18 +0200 MIME-Version: 1.0
Received: from lists.XCF.Berkeley.EDU ([128.32.112.242]) by mc11-f15.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 25 Sep 2003 11:35:45 -0700
Received: from lists.XCF.Berkeley.EDU (unknown [127.0.0.1])by lists.XCF.Berkeley.EDU (Postfix) with ESMTPid 5BEDC103B1; Thu, 25 Sep 2003 11:45:30 -0700 (PDT)
Received: from penguin.kabelta.cz (unknown [212.11.121.19])by lists.XCF.Berkeley.EDU (Postfix) with SMTP id 46757102CCfor ;Thu, 25 Sep 2003 11:32:14 -0700
(PDT)
Received: (qmail 1784 invoked from network); 25 Sep 2003 18:18:18 -0000 Received: from localhost (HELO centrum.cz) (127.0.0.1) by localhost with SMTP; 25 Sep 2003 18:18:18 -0000
X-Message-Info: yilqo4+6kc43tBKQfUgFUHBFfx51X4Ib Delivered-To: gimp-developer@lists.xcf.berkeley.edu Message-ID:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030807 X-Accept-Language: cs, en-us, eo
References:
In-Reply-To:
X-BeenThere: gimp-developer@lists.xcf.berkeley.edu X-Mailman-Version: 2.1b4
Precedence: list
List-Id:
List-Post:
List-Subscribe:
,
List-Unsubscribe:
,
List-Archive:
List-Help:Sender: gimp-developer-bounces@lists.xcf.berkeley.edu Errors-To: gimp-developer-bounces@lists.xcf.berkeley.edu Return-Path: gimp-developer-bounces@lists.xcf.berkeley.edu X-OriginalArrivalTime: 25 Sep 2003 18:35:46.0183 (UTC) FILETIME=[D57F5970:01C38393]
I believe we could hard-code two keybindings to work as the default, couldn't we?
Technically possible, but extremely horrible, since the user has to be educated about it. And since the only argument in favour of the less ergonomic C-S-Z is "easier to learn", that sounds even worse than leaving it at C-R.
I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z. Then if you move from photoshop or HIGified Gnome apps, it will work for you. But the (IMHO) much more ergonomic C-R stays as the default for newbies. As it was said earlier the ergonomics of Redo operation in for example text editor is less important as you don't use it so often and you don't switch between Undo and Redo very fast and frequently.
Tom Mraz
sounds like a good option, of course, it would confuse things if a user wants to apply SH+CT+Z to some other function(not sure why they'd want to, but it's possible).
just out of interest, what on earth made the GNOME HIG people think that SH+CT+Z was a good combo for anything? and is there a good reason (HIG rules wise) for not allowing use of CT+R? it's not like there's a refresh of reload funciton in GIMP(although it could be handy, i still wouldn't want it attached to CT+R)
you've got to remember that from a Photo$hop perspective undo and redo are unimportant, everything's done with history, and undo is normally only one level(that's how i remember those horrible experiences anyway) or is it Ct+Z becomes Redo once you've undone once, either way, it's deeply unpleasant and i don't want to talk about it :P
Phil.
__________________
Redo shortcut
philharper@hotmail.com (2003-09-26 at 1933.11 +0000):
I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z.
sounds like a good option, of course, it would confuse things if a user wants to apply SH+CT+Z to some other function(not sure why they'd want to, but it's possible).
Grouped undo, or call undo history, ie. Hardcoding would be more problem than harm, btw.
just out of interest, what on earth made the GNOME HIG people think that SH+CT+Z was a good combo for anything? and is there a good reason (HIG rules wise) for not allowing use of CT+R? it's not like there's a refresh of reload funciton in GIMP(although it could be handy, i still wouldn't want it attached to CT+R)
Probably a mix of "related to undo" with "used in other places" reasonings. If you want a real answer, ask them.
They did not have any problem about changing button order from the most used one (important button on left side, for LTR languages) to the easier to use one (imporant on right side), OTOH, so logic behind when to change and when not is fuzzy for me. And they proposed shortcuts seem to be text editor / browser oriented, while other kinds of apps seems to be ignored.
GSR
Ooops, error (Re: Redo shortcut)
famrom@infernal-iceberg.com (2003-09-26 at 2226.34 +0200):
Grouped undo, or call undo history, ie. Hardcoding would be more problem than harm, btw.
Argh! "...problems than help, btw."
GSR
Redo shortcut
Guillermo S. Romero / Familia Romero wrote:
philharper@hotmail.com (2003-09-26 at 1933.11 +0000):
I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z.
sounds like a good option, of course, it would confuse things if a user wants to apply SH+CT+Z to some other function(not sure why they'd want to, but it's possible).
Grouped undo, or call undo history, ie. Hardcoding would be more problem than help, btw.
I meant to hardcode it in such a way, that it could be reassigned by user keybinding preference to other function. Not that I think it's probable that anyone would reassign it to anything.
Tom Mraz
Redo shortcut
* Tom Mraz [030928 15:59]:
Guillermo S. Romero / Familia Romero wrote:
philharper@hotmail.com (2003-09-26 at 1933.11 +0000):
I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z.
sounds like a good option, of course, it would confuse things if a user wants to apply SH+CT+Z to some other function(not sure why they'd want to, but it's possible).
Grouped undo, or call undo history, ie. Hardcoding would be more problem than help, btw.
I meant to hardcode it in such a way, that it could be reassigned by user keybinding preference to other function. Not that I think it's probable that anyone would reassign it to anything.
Not having time to really pay attention,.. sometimes you feel like making some noise anyways.
Since gtk doesn't allow multiple keybindings/action,. why not create a duplicate menu entry that is somehow hidden? By default both bindings would work,.. if the user reassigns the hidden binding, the biggest problem would be presenting an opportunity to re set it.
/Øyvind K.
Redo shortcut
Guillermo S. Romero / Familia Romero wrote:
philharper@hotmail.com (2003-09-26 at 1933.11 +0000):
I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z.
sounds like a good option, of course, it would confuse things if a user wants to apply SH+CT+Z to some other function(not sure why they'd want to, but it's possible).
Grouped undo, or call undo history, ie. Hardcoding would be more problem than harm, btw.
Just to clarify what I meant when I said "hard-coding a value" - since it seems to have caught on as a phrase.
The default value is hard-coded for any given menu item. When
registering the menu item, there is a C function call that
basically does this...
register menu item (name, menu placement, default shortcut);
A registered menu item corresponds to a function being called.
I seem to recall that it was possible to say
register menu item (name, menu placement, default shortcut 1); register menu item (name, menu placement, default shortcut 2);
and have 2 shortcuts to the same menu item. This is not possible in gtk+ 2 (the second shortcut over-writes the first one), so talking about hardcoding several shortcuts is probably useless :)
Note also that the hard-coded shortcut is the default shortcut... it seems that there was some confusion about this above.
There may be hacky ways around this, such as creating "phantom" menu items with one shortcut which are nothing but wrappers around another menu item, but that way leads madness when you throw dynamic shortcuts into the mix.
They did not have any problem about changing button order from the most used one (important button on left side, for LTR languages) to the easier to use one (imporant on right side), OTOH, so logic behind when to change and when not is fuzzy for me.
The button order is used elsewhere (Mac). It should be used in conjunction with better dialogs (action verbs such as "Save", "Revert", "Don't save" rather than "Yes", "No", "Cancel"). And the logic behind it is simply that humans using LTR languages read dialogs from the top left to the bottom right, so the default action should be on the bottom right.
Cheers, Dave.
Redo shortcut
dneary@free.fr (2003-10-01 at 0852.29 +0200):
They did not have any problem about changing button order from the most used one (important button on left side, for LTR languages) to the easier to use one (imporant on right side), OTOH, so logic behind when to change and when not is fuzzy for me.
The button order is used elsewhere (Mac). It should be used in conjunction with better dialogs (action verbs such as "Save", "Revert", "Don't save" rather than "Yes", "No", "Cancel"). And the logic behind it is simply that humans using LTR languages read dialogs from the top left to the bottom right, so the default action should be on the bottom right.
Fine, I know about the order and the verbs, so I can not understand why there seems to be a blind reasoning about shortcuts: not every app requires the same functions nor the same usage pattern, so settings lots of shortcuts that only seem to match text editors and browser seems unreasonable. Gimp has collisions with other keys, you just changed one, but there are more, if you want to comply, your work is half done... and I will change back in my own config to make things nice for a Gimp user instead than for a HIG writer. HIG is not set in stone, and even then, it can be wrong.
GSR
Redo shortcut
On Wed, 1 Oct 2003 17:32:39 +0200, "Guillermo S. Romero / Familia Romero" wrote:
Fine, I know about the order and the verbs, so I can not understand why there seems to be a blind reasoning about shortcuts: not every app requires the same functions nor the same usage pattern, so settings lots of shortcuts that only seem to match text editors and browser seems unreasonable.
It does not "only seem to match text editors and browsers". The first examples of shortcuts that were posted at the beginning of this discussion (previous thread) mentioned the shortcuts used in Photoshop and Paint Shop Pro on Mac and Windows.
Gimp has collisions with other keys, you just changed one, but there are more, if you want to comply, your work is half done... and I will change back in my own config to make things nice for a Gimp user instead than for a HIG writer. HIG is not set in stone, and even then, it can be wrong.
Yes, but on the other hand we should not invent or keep old shortcuts that are not used by any other applications if it would be possible to use some well-known shortcuts without significant drawbacks. Using the same shortcuts as some other applications would be a great help for the new users. So from my point of view, the list of choices for the Redo shortcut contains only two alternatives: Ctrl-Shift-Z or Ctrl-Y. We should pick one of these, but not the old shortcut.
-Raphaël
Redo shortcut
Hi,
Raphaël Quinet writes:
It does not "only seem to match text editors and browsers". The first examples of shortcuts that were posted at the beginning of this discussion (previous thread) mentioned the shortcuts used in Photoshop and Paint Shop Pro on Mac and Windows.
The Photoshop Undo feature is completely different from GIMP's way of handling Undo. The PhotoShop shortcut thus doesn't have much weight in this discussion.
Sven
