Which keyboard layout is this about?

My keyboard layout is QWERTY, if that's what you meant.

That means US? Or british? :)

Multiple countries use Qwerty, and there may be other special settings involved - see http://en.wikipedia.org/wiki/Keyboard_layout

Please describe everything you can think of that would make your keyboard setup special.

I have a PS2 keyboard plugged into my laptop (I tried using the laptop keyboard; same thing happened).

I looked at the Wikipedia article; I think I have a keyboard with a US layout, with a numbpad (as part of the keyboard). 

It looks similar to this:
http://www.dyslexic.com/mmDYSLEXIC/Images/w_optical-desktopPro_a.jpg

The thing that struck me as unusual was that it registered an "@" symbol for Shift+2, instead of registering the Shift+2. In general it seems to register other strokes like Shift+Ctrl+E.

Indeed, most likely my fault because I changed quite some stuff around
accelerators in GTK+.

*** Bug 711702 has been marked as a duplicate of this bug. ***

Perhaps this should be reported as a separate minor bug but could perhaps be tidied up at the same time - the short-cuts for "Tools/Decrease Value 2 More" and "Tools/Increase Value 2 More" don't work for me when set to the default settings of "Shift [" and "Shift ]". On my keyboard "Shift [" is "{" - setting "{" (or "Ctrl {" or "Alt {") works without a problem. Given that the short-cut for "Tools/Decrease Value 1 More" is "Ctrl <" perhaps "Ctrl [" might be appropriate for "Decrease Value 2 More"?

Is bug #677707 a duplicate of this one?  It's recently popped up on the mailing list and occurs under (e.g.) freeBSD and win32 builds of GIMP 2.8 .

It seems to only affect keys whose logical ASCII character differs other than by case ( 1234567890-=[];',./ vs. ~!@#$%^&*()_+{}:"<>? ) , as if GIMP is trapping the shortcut based on its logical character instead of the actual key scan code.  It does NOT occur with letter keys (e.g. I have Paintbrush mapped to B and Bucket Fill mapped to Shift+B and they work just fine).

It's GTK+ doing that, not GIMP.

The same problem exists in GTK+ 3.x

Not sure if this belongs here, or a new bug should be filed, as this is about the cosmetic part on this bug.

I have setup some keyboard shortcuts (meta + shift + 4 for example) and it works as expected, however the UI 'shows' it as 'meta + shift + $'. This is incorrect however. It should be either 'meta + shift + 4' or 'meta + $'. I understand where the bug comes from, it prints that the meta modifier is used, the shift modified is used and the character that's being used, which is shift + 4, or $.

For users however it makes more sense that the shifted character is represented in the UI without the shift modifier. When I press 'shift + 4' as a keyboard shortcut, I expect it to be displayed as its components, rather then the resulting character, confusingly prefixed with the notion that the shift metakey has been pressed.

It doesn't belong here (it's a separare issue) and I'm sure there is
a bug about this against GTK+ (GIMP doesn't handle that itself), but
I don't find that bug or I would refer you to it...

Gimp? The product here says gtk+

I did try to find it, but could not find it either. I will open a seperate issue for this.

Oh, I was in the wrong bug :)

It's been more than 4 years, and this problem has not been fixed. Is there any plan to fix it? If not, is it possible to save the zoom factor when saving the file? I'm working on making a simple GIF animation, and I spend several minutes each session using the mouse to pull down the menu to change the zoom for each file to get all the frames to fit on screen at the same time.

Well afaik, the 'bug' is purely cosmetic, a paper-cut if you will. It's a bug that should be fixed, but the impact is very minimal imo, as it is only about the displaying of the kye in the UI.

Actually, it isn't, the shortcuts are displayed, but don't work.

IIRC there is a workaround using the numeric keypad instead of the number row...?

Otherwise, all you can do is manually remap the key to however GIMP / GTK is receiving it.

(Sidenote: I run GIMP on a laptop whose keyboard does not include a numeric keypad, so workaround #1 simply does not apply.)

@ Olliver Schinagl It's not about displaying the key command. It does display the key command, but the command simply does nothing. This may be of minimal impact to you, but it wastes a lot of my time. I'm working on a GIF animation, and I have to use the mouse to do this several times each session for each and every frame. 

@strata_ranger Neither the keypad nor the number row works for zoom factors smaller than 1. I've tried every possible combination using <Shift>, <Ctrl>, and <Alt>, and nothing works. 

I can't see how it would help to map a different keystroke to a nonworking command. The only way I have found to zoom to, say, 50%, is to use the mouse: View > Zoom > 1:2 (50%). The menu lists the keyboard shortcut as Shift+2, but as stated earlier, that doesn't work. 

This really is a bug in the program code that needs to be fixed.

Shift 2 on (most?) keyboards gives the " (double quote character) - edit the short cut for the command from Shift+2 to " and it will just work (at least it does on the laptop where I have just tried it). Similarly for the other 1:n commands.

This is the same problem as I noted in comment 8 earlier in this thread. I would consider that this wasn't a problem in the program code but an error in the assignment of the short-cut key codes. You would normally not expect to see shift+2 instead of "

Control+Alt+2 also works (if you want to use more fingers) - just don't involve the shift key in any short-cut (apart perhaps from those that use alpha keys (A..Z)).

So I would suggest that any default short-cuts that involve the shift key (for non-alpha keys?) are edited in an up-coming release of GIMP; in the meantime just manually change the short-cut assignments for any of the affected keys that you use. Hope that this saves you much mouse work.

^ Actually, on most (e.g. US qwerty) keyboards Shift+2 produces an @ symbol; it's Shift+' that produces ".

But otherwise, again, just go to your Keyboard Shortcuts settings and manually remap the keys, then they will work again.

Sidenote, key shortcuts are saved to your GIMP menurc file.  Look it up and you should find entries like these:

(gtk_accel_path "<Actions>/view/view-zoom-1-2" "<Shift>2")
(gtk_accel_path "<Actions>/view/view-zoom-1-4" "<Shift>3")
(gtk_accel_path "<Actions>/view/view-zoom-1-8" "<Shift>4")
(gtk_accel_path "<Actions>/view/view-zoom-1-16" "<Shift>5")

Those are the default settings (which don't work), but once you've remapped the keys and saved settings, those same entries are now this:

(gtk_accel_path "<Actions>/view/view-zoom-1-2" "at")
(gtk_accel_path "<Actions>/view/view-zoom-1-4" "numbersign")
(gtk_accel_path "<Actions>/view/view-zoom-1-8" "dollar")
(gtk_accel_path "<Actions>/view/view-zoom-1-16" "percent")

So we can see that this isn't "just a display issue", GTK is in fact not receiving the keystroke correctly so the default mappings (albeit technically correct) are never actually recognized as such.

As a work-around each GIMP user who needs short-cuts that involve the shift key being combined with a non-alpha keys can edit the keys that they wish to use but this doesn't seem like a professional approach.

Would it be possible to have GTK recognised that entries such as "<Shift>2" need to be interpreted based on the selected keyboard? The user would then still see Shift+2 displayed as the short-cut in the menu and could press the shift key and the 2 key without having to consider what character would normally result from this key combination.

(In reply to OldOllie from comment #20)
> @ Olliver Schinagl It's not about displaying the key command. It does
> display the key command, but the command simply does nothing. This may be of
> minimal impact to you, 
> 
then I missunderstood, as the keybindings work just fine for me, except them being displayed oddly. Sorry for misunderstanding.

(In reply to Olliver Schinagl from comment #24)

No, problem, Olliver. I was able to complete the task using the mouse to zoom out; it just took a bit longer. At least I can still use the keyboard to zoom to 100% or larger. I still have a couple of dozen more illustrations to do, though, so a quick resolution by the developers would be most appreciated. 

BTW, I'm using a 20-year-old standard PS/2 AT keyboard, so there's nothing exotic about it.

(In reply to OldOllie from comment #25)
> (In reply to Olliver Schinagl from comment #24)
> 
> No, problem, Olliver. I was able to complete the task using the mouse to
> zoom out; it just took a bit longer. At least I can still use the keyboard
> to zoom to 100% or larger. I still have a couple of dozen more illustrations
> to do, though, so a quick resolution by the developers would be most
> appreciated. 
> 
> BTW, I'm using a 20-year-old standard PS/2 AT keyboard, so there's nothing
> exotic about it.

"I can't see how it would help to map a different keystroke to a nonworking command. The only way I have found to zoom to, say, 50%, is to use the mouse: View > Zoom > 1:2 (50%). The menu lists the keyboard shortcut as Shift+2, but as stated earlier, that doesn't work. "

Your "quick resolution" (at least for the short-term) was provided for you in comments posted above on the 4th of September!

To spell it out - just follow these steps:

1. Activate GIMP
2. In the menus - "Edit/Keyboard Shortcuts"
3. Expand the "View" section
4. Scroll down to the "1:2 (50%)" command and left-click on it
5. Hold down the Shift key and then press the 2 key - the short-cut will now show whatever character you get when you hold down shift and 2 (and the View/Zoom 1:2 menu will show this character).

Now when you want to zoom to 50% just hold down Shift and press 2.

Make similar edits to the 1:4, 1:8 and 1:16 short-cuts.

"This really is a bug in the program code that needs to be fixed."
No, this is an error (or perhaps an improperly thought through idea) in the allocation of the short-cut keys as noted above.

The point is that it is easy to configure the short-cut keys to do exactly what you want - all 4 of these 1:n short-cuts can be configured in this way in a much shorter time than it has taken me to type this!

> so a quick resolution by the developers would be most appreciated. 

Unless we're talking geological timescales, such a thing simply does not exist.
(But seriously, folks.)

The *quickest* resolution here is to just remap the keys yourself.  I agree it's not the *best* solution, but it *works*, and then you'll have working shortcut keys like you want.

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

Cannot say whether it still occurs with current GTK+, particularly the 3.x branch as GIMP is still bundled with GTK+2.x in releases.

But given that GIMP effectively ships with some broken default shortcuts (see comment #22) I would say yes it is still relevant to GIMP, even with a functioning workaround available (remap those shortcuts manually, then they work).

Yes this still happens with GTK+ 3.x, reopening.

-- 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/gtk/issues/395.