On Sun, Sep 21, 2003 at 11:22:46AM +0200, David Neary wrote:

Are there any objections to this keymap change?

Why not Ctrl-Z, which is faster and which almost everybody knows already?

/* Steinar */

On 21 Sep 2003, at 14:12, David Neary wrote:

Steinar H. Gunderson wrote:

Why not Ctrl-Z, which is faster and which almost everybody knows already?

Excuse me - the shortcut I'd like to change is Redo, which is currently Ctrl-R. Most apps in the Linux desktop space are now adopting some or all of the GNOME HIG in this regard. So - to correct myself - I'd like to change Ctrl-R to Ctrl-Shift-Z.

I have always understood and accepted why some of the GIMP functionality (or lack thereof) seems a bit Linuxy. After all, most developers like to use Linux, so you get a natural bias.

But since when did GIMP _users_ all start living there? Do we know what the guidelines for other platforms are? How useful are the HIG?

On 21 Sep 2003, at 14:51, Branko Collin wrote:

On 21 Sep 2003, at 14:12, David Neary wrote:

Steinar H. Gunderson wrote:

Why not Ctrl-Z, which is faster and which almost everybody knows already?

Excuse me - the shortcut I'd like to change is Redo, which is currently Ctrl-R. Most apps in the Linux desktop space are now adopting some or all of the GNOME HIG in this regard. So - to correct myself - I'd like to change Ctrl-R to Ctrl-Shift-Z.

I have always understood and accepted why some of the GIMP functionality (or lack thereof) seems a bit Linuxy. After all, most developers like to use Linux, so you get a natural bias.

But since when did GIMP _users_ all start living there? Do we know what the guidelines for other platforms are? How useful are the HIG?

I looked a bit further into this. Relevant links can be found in the Future section at .

GNU/Gnome says:

"Use Shift-Ctrl-letter for functions that reverse or extend another function. For example, Ctrl-Z and Shift-Ctrl-Z for Undo and Redo. Note that you cannot use Shift-Ctrl-A-thru-F, however, as these combinations are used to enter unicode characters in text fields.

Function Shortcut Description Undo Ctrl-Z Undo the last operation Redo Shift-Ctrl-Z Redo the last operation"

Microsoft says:

[nothing]

I could only find a recommendation to use Ctrl-Z for Undo. It could be that MS uses a different term for Redo, so that I could not find anything for that.

Apple says:

"Use the Command key as the main modifier key for keyboard equivalents. For a command that complements another more common command, you can add Shift. The table below shows some recommended keyboard equivalents using Shift.

Table 9-8 Some of the recommended keyboard equivalents using Shift to complement other commands

Keys Command Complemented command
Shift-Command-A Deselect All Command-A (Select All)
Shift-Command-G Find Previous Command-G (Find Again)
Shift-Command-P Page Setup Command-P (Print) Shift-Command-S Save As Command-S (Save) Shift-Command-V Paste as (Quotation, for example) Command-V (Paste) Shift-Command-Z Redo Command-Z (Undo)

Note: Shift-Command-Z would be used for Redo only if Undo and Redo are separate commands (rather than toggled using Command-Z).

If there?s a third, less common command that?s related to a pair of commands that use Command and Shift-Command, you can use Option- Command for the third command?s keyboard equivalent. In the example in Table 9-9, Save All could be a dynamic menu item (see ?Menu Behavior?) that appears in place of Save when the user presses the Option key (rather than a separate menu item). Use combinations like these very rarely."

So, as you can see, Apple and Gnome are basically in agreement (although their different wording, 'complement' versus 'reverse or extend', may lead to differences in keyboard shortcut assignments).

On 21 Sep 2003, at 15:46, David Neary wrote:

Branko Collin wrote:

On 21 Sep 2003, at 14:12, David Neary wrote:

Excuse me - the shortcut I'd like to change is Redo, which is currently Ctrl-R. Most apps in the Linux desktop space are now adopting some or all of the GNOME HIG in this regard. So - to correct myself - I'd like to change Ctrl-R to Ctrl-Shift-Z.

But since when did GIMP _users_ all start living there? Do we know what the guidelines for other platforms are? How useful are the HIG?

This was also something that was addressed in the old threads, I believe... Here's the mail in question. https://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008870.h tml

Well, certainly both current practice and HIGs are against me. Quite frankly, the former weighs heavier with me.

Still, it feels unintuitive somehow. Usually, with a complementary function, you get to see an immediate difference. For instance, the Print Preview dialog is clearly different from the Print dialog. Having Ctrl-P and Shift-Ctrl-P for these makes sense, because if you accidentally hit the wrong keys, you have immediate feedback that shows your mistake.

However, the difference between hitting Shift-Ctrl-Z and Ctrl-Z is not always apparent, unless you always have the Undo History open and visible. So it would make sense to have the complementing function under a shortcut that won't be easily accessed by mistake.

Anyway, I don't think we're going to agree on this, so as far as I am concerned, go ahead and make the change.

BTW, I read in the Windows HIG that several shortcuts per function are supported, for reasons of backward compatibility. Would it be possible to have something similar in the GIMP?

I've got a bunch of plugins on my website, a couple of which are reasonably stable and mature. (OK, so they're built against 1.2 at the moment.) Who decides on the offical plugin list?

For the interested, check out wideangle, degrain, and DBP (and maybe Cineon/DPX, although that's fairly specialised) at:

http://members.ozemail.com.au/~hodsond/

http://wiki.gimp.org/ is a nice holding place until the other stuff gets ironed out, imo.

carol

David Hodson wrote:

I've got a bunch of plugins on my website, a couple of which are reasonably stable and mature. (OK, so they're built against 1.2 at the moment.) Who decides on the offical plugin list?

For the interested, check out wideangle, degrain, and DBP (and maybe Cineon/DPX, although that's fairly specialised) at:

http://members.ozemail.com.au/~hodsond/

"Branko Collin" wrote:

[...]

BTW, I read in the Windows HIG that several shortcuts per function are supported, for reasons of backward compatibility. Would it be possible to have something similar in the GIMP?

YES, please!!

I fully agree that Shift-Ctrl-Z is The Right Thing To Do. Even if it's not a very known fact, some of the Windows system shortcuts (and some applications also follow the same idea) use Shift to reverse the operation of a command, e.g. Alt-Tab/Shift-Alt-Tab to switch to next/previous app, Ctrl-Tab/Shift-Ctrl-Tab to go to the next/previous window in a MDI application, Alt-Esc/Shift-Alt-Esc to go to the next/previous item in the taskbar, and some others that I don't remember/know. Notably there are even some applications such as Delphi that support both Ctrl-Z and Alt-Backspace for undo, and both Shift-Ctrl-Z and Shift-Alt-Backspace for redo. MSPaint is not an example, though it uses Alt-Backspace for undo as well as Ctrl-Z. This tries to fill the space left by Branko Collin about what MS says, even if it does not say anything explicitly. :)

However I *love* the Ctrl-R binding, especially because it lets me quickly compare the done and undone versions of an image using a single hand with very little effort. Try to do it with Ctrl-Z/Shift-Ctrl-Z and you'll find that you need either very good coordination between fingers (better than the one I have at least) or to use both hands.

So, if it's possible to have two different keybindings for the same command I'd like very much to have both.

BTW, the mail program I'm using right now (Forte Agent) uses Ctrl-R to redo.

Hi,

usr352@wanadoo.es writes:

However I *love* the Ctrl-R binding, especially because it lets me quickly compare the done and undone versions of an image using a single hand with very little effort. Try to do it with Ctrl-Z/Shift-Ctrl-Z and you'll find that you need either very good coordination between fingers (better than the one I have at least) or to use both hands.

Ack. IMHO the new keybinding (David changed it already) is really akward to use compared to the old one. And actually Ctrl-Shift-Z should better be left available so we can bind it to group undos later when this feature is implemented. (A group undo would allow to undo all operations of the same type found at the top of the undo stack, for example all paint strokes).

Sven

On Tue, 2003-09-23 at 10:01, David Neary wrote:

I'm not sure the plug-in registry likes anyone :) Who *is* responsible for maintaining it?

According to http://registry.gimp.org/changes?max=15 the last change to a plug-in was done only a couple of days ago - so it seems the registry works at least for some people.

In the meantime, as Carol suggested it might be an idea to use the wiki to collect these kinds of external resources, in the absence of a registry which gets updated.

Hmmm... another duplication of effort? Why have two places to store user committed plug-ins? Wouldn't the time be better spent on say, maintaining registry.gimp.org?

Sincerely, ./Brix

David Neary wrote:

I'm not sure the plug-in registry likes anyone :) Who *is* responsible for maintaining it?

Ingo is listed as the contact, and his email address is there. I did get a reply from him when I was having problems (in May this year), but we couldn't solve them. (Or maybe I lost interest.)

(BTW, sorry I replied to you instead of the list.)

Carol Spears wrote:

http://wiki.gimp.org/ is a nice holding place until the other

> stuff gets ironed out, imo.

OK, I've put DBP up there because I think it's the most useful. I might add some others later. Let me know (or, I guess, just edit it) if I've done something horribly wrong.

/me returns from the hurricane, finally able to catch up on several days worth of email.

On Mon, 22 Sep 2003 usr352@wanadoo.es wrote:

However I *love* the Ctrl-R binding, especially because it lets me quickly compare the done and undone versions of an image using a single hand with very little effort. Try to do it with Ctrl-Z/Shift-Ctrl-Z and you'll find that you need either very good coordination between fingers (better than the one I have at least) or to use both hands.

I agree. Gimp's undo and redo feature differs from many other programs in that when comparing subtle changes it is useful to switch rapidly between the "before" and "after" views, while for a program such as a word processor, that is probably not a useful thing to do. This being the case, this particular need of GIMP users was probably not considered by the HIG.

Personally, I compare between the "before" and "after" by holding down control and hitting z or r as necessary. For some changes, I switch several times a second, as the human eye is remarkably able to detect small differences when they are animated.

Switching between views this fast with accuracy is simply not possible using Shift-Ctrl-Z due the the physiology of the human hand. The optimal hand position is left on the shift and control and right on the z, with the finger on the shift moving every other beat of the other hand and the finger on the control key staying still.

Here the body's natural cordination works against switching views quickly, as the nervous system will assume that the finger on the R key and that on the shift key should really be synchronized. This leads to errors. With the old bindings the natural cordination system helps to acomplish the task accurately and faster.

So, if it's possible to have two different keybindings for the same command I'd like very much to have both.

Unfortunately, it is not. Really, GTK should be made more flexable in this regard, but it is not a trival problem, due to how GTK handles accelerators.

Since we only can choose one, it makes sense that we choose the one that ergonomics favors. I'm sure that in this case most usability people would say that actually being able to use the feature is more important than consistancy with some other apps. Especially because this particular funciton isn't particularly consistant between apps.

On the other hand, we could go for both ergonomics and consistency by using MS Office's Ctrl-Y. Note that I am not recommending it. I think keeping redo the way it is in 1.2 is the best policy.

BTW, the mail program I'm using right now (Forte Agent) uses Ctrl-R to redo.

There we go, between that and tradition, we have all the justification we need. ;)

Rockwalrus

David Neary wrote:
> Henrik Brix Andersen wrote:
>>According to http://registry.gimp.org/changes?max=15 the last change to >>a plug-in was done only a couple of days ago - so it seems the registry >>works at least for some people.
>
> Perhaps, but there are several things which should be possible > which aren't.
>
> First, the majority of the plug-ins in the registry appear to be > abandonware - 1.0 plug-ins that have never been updates to 1.2, > never mind 1.3/2.0. We need a way to clean out the cruft (or at > least hide it away).
>
> Second, the registry could do with a ranking system to have the > most common and/or popular plug-ins appearing on the top of the > lists of plug-ins. The only sorting system I've seen is > alphabetically, which severely limits the usefullness of the site. >
> Third, it is not possible to attach patches for existing > plug-ins to a plug-in without being a plug-in maintainer. It > would be nice if this were easier to do, perhaps with a comment > system? Although I guess an inscription system makes some > sense...

Fourth, there needs to be a way to recover your password or something! My plugins died in the registry because the ability to update them was locked to an account that I'd forgotten the password to.

--Adam

On Tue, 23 Sep 2003, David Neary wrote:

Henrik Brix Andersen wrote:

According to http://registry.gimp.org/changes?max=15 the last change to a plug-in was done only a couple of days ago - so it seems the registry works at least for some people.

Perhaps, but there are several things which should be possible which aren't.

First, the majority of the plug-ins in the registry appear to be abandonware - 1.0 plug-ins that have never been updates to 1.2, never mind 1.3/2.0. We need a way to clean out the cruft (or at least hide it away).

Second, the registry could do with a ranking system to have the most common and/or popular plug-ins appearing on the top of the lists of plug-ins. The only sorting system I've seen is alphabetically, which severely limits the usefullness of the site.

Third, it is not possible to attach patches for existing plug-ins to a plug-in without being a plug-in maintainer. It would be nice if this were easier to do, perhaps with a comment system? Although I guess an inscription system makes some sense...

This functionality sounds a lot like MozDev, which has a very useful list of active projects, or Sourceforge (or Gnu/Savannah/Whatever).

Changing to a full blown project management system might make things easier to manage in the long run.

Something to consider at least.

- Alan H

usr352@wanadoo.es (2003-09-22 at 1959.36 +0200):

So, if it's possible to have two different keybindings for the same command I'd like very much to have both.

You can always redefine commands, I will, I prefer the finger-dance with two letters than with modifiers. Related to this, on IRC we have been talking about undo ideas, for the future.

One was some kind of grouped undo (using Shift, that is the link to this thread), but not clear how it should behave. When you are painting, you can do lot of strokes, and undo one by one is tedious and slow (so would be redo), suposing you do not waste all undo steps. Thanks to the new system, consuming undo steps is no such big issue like in previous Gimps (check the part about storing undo info if memory is avaliable, in preferences).

But the workflow problem is still there. Undo history window can help... sometimes. For example painting or drawing (hundreds of strokes without changing tool) are not in those cases, cos the preview is not enough for the task (the size of it vs the size of the real change) and the description text saying the same always.

If all is undone as Sven proposes... I think you can change workflow to use new layers or cloned layers, and forget about undo (discard layer = undo). That plus Revert is what I have been doing in 1.2, to cope with limited undo stack and single step undo (but not happy with it).

Thus the next idea is choosing how many normal steps should be a group one, and if limiting it to "same kind" of step (IMHO, yes). I would put it in preferences with the other undo things, to cover from "click machine gun" to "all in one stroke" users. That or a spinner in undo history window. The user defines what is his "unit" for an important change, be it 5 or 50.

Side of effect of grouping, it could be used to compact really old undo steps and save memory. Another idea floating around was time stamps. It can be interesting in some cases too. But the one that called my attention was grouping, due what I have been doing latelly.

GSR

On Wed, Sep 24, 2003 at 11:39:44PM +0200, David Neary wrote:

I'm sure that ergonomy was considered for Photoshop when they chose Ctrl-Shift-Z for Redo... I do think it's overstating our importance somewhat to say that what's good for a large portion of the rest of the world is not good for us.

"Others do it" is never an argument, though.

What you need are arguments in favour of Ctrl-Shift-Z, and the only ones that there are is "the HIG and other platforms use it, so people are probably used to it, making it easier for them to switch".

That is one aspect of usability. It doesn't have much to do with ergonomics, and as others already have said, Ctrl-R/Ctrl-Z is much more ergonomical than three-key-combinations.

I think "two keys vs. three keys" is extremely obvious, too.

So ergonomics is might have been considered, but it was certainly _dismissed_, as other, much more ergonomic combinations, are available.

Switching between views this fast with accuracy is simply not possible using Shift-Ctrl-Z due the the physiology of the human hand. The optimal hand position is left on the shift and control and right on the z, with the finger on the shift moving every other beat of the other hand and the finger on the control key staying still.

That depends where the z is on the keyboard :)

As a user with german keyboard, I can say that two keys (Ctrl-Z / Ctrl-R) are much easier to toggle than using the proposed three-key combinations.

It's of no importance where the z key is, as it is used in your proposed better solution, too.

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.

It's pretty consistent.

This is true and has been demonstrated :)

And the usability people have considerably more experience with this than either of us :)

usable != ergonomic, though.

And I think that gimp users have considerable more experience with using gimp than the usability people.

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

On Thu, 25 Sep 2003 20:08:02 +0200, David Neary wrote:

In the current situation, I think it's reasonable to fit in with what others do in the general case, which dynamic shortcuts provide a way to revert to the old behaviour. When the others are everyone using a Mac, plus people who come to the GIMP from KDE or GNOME applications, and PhotoShop users, I think the benefits of a familiar keybinding are self-evident.

If you like, I'm arguing populism here. More people use Ctrl-Shift-Z as redu than Ctrl-R. Therefore, until there is a very good reason to change, we should do the same. In addition, a considerable body of usability work reccommends this keymapping.

Just my 0.02 Euro... I agree with Dave: the majority of the GIMP users are using it very seldom and spend most of their time with other applications. So the consistency with other applications should have a large weight when making decisions. And in this case, the drawbacks have a rather low weight because it is easy for the more experienced users to re-assign the shortcut if they are not satisfied with Ctrl-Shift-Z. We should try to help those who are not using the GIMP frequently (yet) as long as the costs for the more experienced users are minimal.

-Raphaël

dneary@free.fr (2003-09-25 at 2008.02 +0200):

You have a point here. I think that what was chosen was the consistency of Shift as negation. I think that's probably a goal

Relation, not just plain negation. So that is why using shift for grouping would be fine.

we could work towards. It certainly makes a lot of logical sense. But then, so does having + to zoom in instead of =, and look how many bug reports that's got us :)

I thought the logic behind = for zoom is that it is in the same key than + (in USA kbds, at least) but people wanted to avoid using Shift. I guess people's logic includes comfort. :]

GSR

David Neary writes:

Marc A. Lehmann wrote:

On Wed, Sep 24, 2003 at 11:39:44PM +0200, David Neary wrote:

I'm sure that ergonomy was considered for Photoshop when they chose Ctrl-Shift-Z for Redo... I do think it's overstating our importance somewhat to say that what's good for a large portion of the rest of the world is not good for us.

"Others do it" is never an argument, though.

It's an argument, just not a very good one (on its own). "Others do it, because it's been shown to be the best way" would be a decent argument, for example (I'm not arguing this).

In the current situation, I think it's reasonable to fit in with what others do in the general case, which dynamic shortcuts provide a way to revert to the old behaviour. When the others are everyone using a Mac, plus people who come to the GIMP from KDE or GNOME applications, and PhotoShop users, I think the benefits of a familiar keybinding are self-evident.

Is familiarity an argument when what's "familiar" is *way* less comfortable than the less-familiar but better shortcut?

IMHO needing to toggle between undo and redo is an absolute usability desaster. The reasons have been said earlier in this thread: repetitive undo/redo is a a common operation in graphics applications, unlike e.g. text editors.

I completely follow the rationale of consistency but IMHO usability overweights it.

If you like, I'm arguing populism here. More people use Ctrl-Shift-Z as redu than Ctrl-R. Therefore, until there is a very good reason to change, we should do the same. In addition, a considerable body of usability work reccommends this keymapping.

Yes, and more applications are text editors or word processors or similar things where this absolutely makes sense. Is it our fault that the HIG guys only have GEdit in mind when they write down stuff?

And btw, a considerable percentage of mails in this thread voted for ctrl+R, does this count less than questionable "consistency"?

What you need are arguments in favour of Ctrl-Shift-Z, and the only ones that there are is "the HIG and other platforms use it, so people are probably used to it, making it easier for them to switch".

Yes, that's about it. It's also that current GIMP users probably benefit from having the same keybindings everywhere. There's nothing that annoys me more than using emacs, getting back into the emacs keybindings, and then using vim, and freezing the terminal with C-x C-s. Of course, this is not like with like. But I imagine that people who use both the gimp and photoshop have dozens of little annoyances like these.

I guess people will rather find it annoying to do complicated trick using three instead of two fingers. Have you ever looked what photoshop *really* does when pressing the undo shortcut several times? Following them when it comes to undo key bindings is the worst we could do...

That is one aspect of usability. It doesn't have much to do with ergonomics, and as others already have said, Ctrl-R/Ctrl-Z is much more ergonomical than three-key-combinations. I think "two keys vs. three keys" is extremely obvious, too. So ergonomics is might have been considered, but it was certainly _dismissed_, as other, much more ergonomic combinations, are available.

You have a point here. I think that what was chosen was the consistency of Shift as negation. I think that's probably a goal we could work towards. It certainly makes a lot of logical sense. But then, so does having + to zoom in instead of =, and look how many bug reports that's got us :)

And the usability people have considerably more experience with this than either of us :)

usable != ergonomic, though.

Fair enough.

And I think that gimp users have considerable more experience with using gimp than the usability people.

If the GIMP were the only graphics application choosing this keybinding I would agree. I guess that when in doubt, following the crowd is a fairly safe bet (note this leaves open the possibility of not following the crowd when not in doubt ;).

I don't know about others' doubts, but I have no doubt that we should keep +R, since we are not talking about feature xy of application xy (how often do you use undo in your word processor), but we talk about the most-used shortcuts in the GIMP. Making them less accessible is no option IMHO.

ciao, --mitch

On Fri, 26 Sep 2003 15:22:05 +0200, Michael Natterer wrote:

David Neary writes:

In the current situation, I think it's reasonable to fit in with what others do in the general case, which dynamic shortcuts provide a way to revert to the old behaviour. When the others are everyone using a Mac, plus people who come to the GIMP from KDE or GNOME applications, and PhotoShop users, I think the benefits of a familiar keybinding are self-evident.

Is familiarity an argument when what's "familiar" is *way* less comfortable than the less-familiar but better shortcut?

IMHO, yes. It does not matter how awkard a keybinding is - if you cannot remember it, you might as well not use it. If those who do not use the GIMP frequently can remember the Redo shortcut easily, then it will be easier for them to use the program. And anyone who use the shortcut frequently (all experienced GIMP users do) can bind it to some other key, such as Ctrl-Y, Ctrl-R or anything else.

IMHO needing to toggle between undo and redo is an absolute usability desaster. The reasons have been said earlier in this thread: repetitive undo/redo is a a common operation in graphics applications, unlike e.g. text editors.

I completely follow the rationale of consistency but IMHO usability overweights it.

I agree with your arguments, but disagree with the conclusion. ;-)

[...]

And btw, a considerable percentage of mails in this thread voted for ctrl+R, does this count less than questionable "consistency"?

How many of these mails have been written by the 99% of the users who do not use the GIMP more than once per week (or month)? Yes, I am teasing you. ;-)

[... big snip ...]

I don't know about others' doubts, but I have no doubt that we should keep +R, since we are not talking about feature xy of application xy (how often do you use undo in your word processor), but we talk about the most-used shortcuts in the GIMP. Making them less accessible is no option IMHO.

If your main argument is that we should not have more than one modifier for Redo because it is used frequently (I agree with that, but I think that we should let the users rebind this _if they really need it_), then we should not use Ctrl-R. We could use Ctrl-Y, because there is a chance that it would be consistent with some other programs. But we should not keep Ctrl-R if all other applications have chosen different shortcuts. Historical reasons are not valid because otherwise we would never be able to improve the user interface.

So the choice should be between Ctrl-Shift-Z and Ctrl-Y. I prefer the former, for the reasons that I have stated in another message. I could live with the latter, but please do not bring back the old Ctrl-R.

-Raphaël

Raphaël Quinet wrote:

How many of these mails have been written by the 99% of the users who do not use the GIMP more than once per week (or month)? Yes,

Do I count?

When I have to redo in an app that I don't use frequently, I use the Edit menu to see how it's done. That was once the case of The GIMP, and when I used it a few times I found it useful, comfortable and even mnemonic (definitively more than Ctrl-Z was when I started using it).

So the choice should be between Ctrl-Shift-Z and Ctrl-Y. I prefer the former, for the reasons that I have stated in another message. I could live with the latter, but please do not bring back the old Ctrl-R.

Unification (i.e. following the HIG) is desirable; I'm tired of having to switch my mind whenever I switch to another editor, to adapt to the new keybindings. I frequently use by mistake one editor's keybindings while I'm using another. For this reason I like the idea of a harcoded Shift-Ctrl-Z. The problem that Phil Harper mentions in another message (the user wanting to use Shift-Ctrl-Z for something else) is not a problem if the user's redefinition takes precedence over the hardcoded keybinding.

But leaving it up to the user to customize the keybinding is letting it die. Fully customizing an app to make it feel like another is sometimes a several hours work. Furthermore, in future someone can forget that some day Ctrl-R was used for Redo (or just be attracted to use it for something else because it's available), and bind that combo to something different. Then the Ctrl-R-for-redo lovers will have to change two keybindings instead of one. That's an additional step that adds annoyance, not to mention that it's difficult to know in advance which keybindings are free to assign to the new function.

Imagine the following scenario. Suppose that Ctrl-R is used by default for, say, refresh the image, while Ctrl-Shift-Z is Redo. Mrs. User wants to use Ctrl-R for Redo, so the first step is to choose a free keybinding for refreshing the image. Of course, Ctrl-Shift-Z is not a good choice for her, either because she hates it or because she just doesn't feel it's convenient or whatever. For that reason she has to find a keybinding convenient for her and not already in use.

When I face this kind of problem, I tend to leave the default settings as they are, trying to conform to the idiosyncratic behaviour of the application, and I think that I represent a vast amount of users in this respect. Killing Ctrl-R is a direct attack to the heart of The GIMP. If the user happens to be an experienced GIMP user, she will have good reasons to complain, and I can figure out Bugzilla full of dupes of the same report wanting Ctrl-R back.

However, leaving it as the default in the menu does not hurt if Shift-Ctrl-Z is available for those who are HIG- (or PS-) oriented.

That's just my opinion, of course, which as most opinions, is not humble nor attempts to be.

Hi,

I wonder when and why the terminology of hardcoding a keybinding was introduced into this discussion. I simply don't understand it's meaning. If you think about having two different keybindings bound to a single menu entry, this is AFAIK not possible with GTK+-2.x. And I can't think of any other sensible way of adding a second keybinding. Please try to keep this in mind when discussing this topic. We need to settle on a single sensible default keybinding. I don't think there are alternatives to this, so you are only wasting your time by discussing them.

Sven

On Thu, 2003-09-25 at 19:08, David Neary wrote:

If you like, I'm arguing populism here. More people use Ctrl-Shift-Z as redu than Ctrl-R.

Having said that, there are probably more (non-gtk/GNOME) apps out there that use Ctrl-Y than either Ctrl-Shift-Z or Ctrl-R :)

If the GIMP were the only graphics application choosing this keybinding I would agree. I guess that when in doubt, following the crowd is a fairly safe bet (note this leaves open the possibility of not following the crowd when not in doubt ;).

Somebody pointed out earlier that GIMP is kind of a special case for Undo/Redo because you often want to flip quickly between the two states. I have some sympathy for that argument, but remember also that for much the same reason, GIMP provides a special tool (the Undo window) in which you can quickly toggle between any two consecutive historical states using only the up and down arrow keys, which is even more ergonomically-friendly than Ctrl-anything :) I guess the question is whether it's worth going against the HIG on ergonomic grounds, when the application already provides a more efficient way to achieve the same effect anyway. (Although admittedly it's only " more efficient" once you've actually navigated to the Undo dock in the first place.)

Whimsical muse: since there are almost no other gtk/GNOME apps that use Redo (and the only one I can think of doesn't use Ctrl-Shift-Z either), it's not beyond the bounds of possibility that we might end up changing the HIG to whatever you decide anyway :)

Cheeri, Calum.

Calum Benson wrote:
: On Thu, 2003-09-25 at 19:08, David Neary wrote: :
: > If you like, I'm arguing populism here. More people use : > Ctrl-Shift-Z as redu than Ctrl-R. :
: Having said that, there are probably more (non-gtk/GNOME) apps out there : that use Ctrl-Y than either Ctrl-Shift-Z or Ctrl-R :) :
: > If the GIMP were the only graphics application choosing this : > keybinding I would agree. I guess that when in doubt, following : > the crowd is a fairly safe bet (note this leaves open the : > possibility of not following the crowd when not in doubt ;). :
: Somebody pointed out earlier that GIMP is kind of a special case for : Undo/Redo because you often want to flip quickly between the two : states. I have some sympathy for that argument, but remember also that : for much the same reason, GIMP provides a special tool (the Undo window) : in which you can quickly toggle between any two consecutive historical : states using only the up and down arrow keys, which is even more : ergonomically-friendly than Ctrl-anything :)

You mistaken. Yust try and see.

o with undo/redo dialog you should use UpDown and therefore do mevements by right hand or press these up/down by left hand's fingers. C-z C-r allows to be psessed without hand's mevements.

o Because of bug or feature of Metacity or EWMH specification this undo/redo dialog stays over image that you edit. Therefore you merely don't see what you undo or redo (in sense you don't see effect of these commands) because drawing area is overlaped/hidded by dialog.

PS. But for me mostly convinient Undo keybinding is `C-_' C-z is used by me as set-mark-command ('start selection' in another words :-)

On 1 Oct 2003, Calum Benson wrote:

Whimsical muse: since there are almost no other gtk/GNOME apps that use Redo (and the only one I can think of doesn't use Ctrl-Shift-Z either), it's not beyond the bounds of possibility that we might end up changing the HIG to whatever you decide anyway :)

Just to mention that Dia has Redo, and we use Ctrl-Shift-Z for it. We used to use Ctrl-R, but decided that was waste of a keybinding. We don't have the frequent undo-redo sequences of Gimp, though.

-Lars

On Mon, Sep 29, 2003 at 12:25:49PM +0200, Sven Neumann wrote:

Hi,

I wonder when and why the terminology of hardcoding a keybinding was introduced into this discussion. I simply don't understand it's meaning. If you think about having two different keybindings bound to a single menu entry, this is AFAIK not possible with GTK+-2.x. And I can't think of any other sensible way of adding a second keybinding.

Well, maybe it's not a sensible way, but you could create another menu entry, somewhere in stupid-quirks/ submenu :-)

I prefer Ctrl-R, btw ;-))))

On Wed, 2003-10-01 at 19:15, Andrew W. Nosenko wrote:

o with undo/redo dialog you should use UpDown and therefore do mevements by right hand or press these up/down by left hand's fingers. C-z C-r allows to be psessed without hand's mevements.

True... I taught myself long ago to use the mouse in my left hand so my dominant right hand was always free for using the keyboard, so I overlooked this small fact :o)

o Because of bug or feature of Metacity or EWMH specification this undo/redo dialog stays over image that you edit.

Well yes, but only if you put it over the image you're trying to edit. If you're working on that part of the image anyway (which you must be if you're looking for changes there), surely you wouldn't place any docks there in the first place...?

Cheeri, Calum.

On Wed, 2003-10-01 at 18:13, Calum Benson wrote:

Whimsical muse: since there are almost no other gtk/GNOME apps that use Redo (and the only one I can think of doesn't use Ctrl-Shift-Z either), it's not beyond the bounds of possibility that we might end up changing the HIG to whatever you decide anyway :)

It sounds like my whimsy may have been interpreted a little less whimsically than intended, so let me clarify... the HIG team are unlikely to change any already-published guidelines without a very good reason, and I would strongly suggest that it's still in everybody's interests to follow the currently-recommended shortcuts where possible, not least (in this case) for people like myself who frequently have to use Photoshop as well, let alone other gtk/GNOME apps!

My comment was purely based on my recollection of some agonization over the choice of shortcut for Redo, and if it turned out that nobody was going to implement it then it would be churlish not to reconsider. However, it would certainly be premature to do that on the basis of the couple of applications I've used which have a Redo feature at all, especially as one of them wouldn't suffer in the least from implementing the recommended shortcut anyway.

In the meantime I fully endorse all GIMP HIG-ification efforts, especially as I'm using it more ofen than ever now :)

Cheeri, Calum.