GNOME Bugzilla – Bug 133453
'universal-keyboard-shortcuts' prevents renaming in non-toolbox dockables
Last modified: 2004-12-22 21:47:04 UTC
because eg P,V,C,L etc keys are assigned as shortcuts to select tools, i can only rename things if the dialog for doing so is docked to the toolbox -- otherwise the shortcutted keys select their respective tools instead of adding characters into the name. example: doubleclick on a brush to bring up the brush editor. try to rename it to eg 'curve' or 'clip'.
I am sorry but I cannot reproduce this problem. Can you please give a detailed instruction on how to reproduce this? Do you have an image open, how's your GIMP setup?
the only requirement is that the brush editor not be docked to the toolbar -- ie when you doubleclick on the brush, it brings up a separate dock containing the brush editor. my setup: the following are docked in a single set of tabs: tool options brushes layers gradients gradient editor paths palette editor palettes other than that i'm not sure what info would be relevant. every brush i've tried it with has this problem; all gradients also have it (assuming gradient-editor isn't docked). doing eg 'rightclick->edit layer attributes' doesn't have this problem, cause the dialog brought up is not a dockable. does this help?
I can still not reproduce the problem. What GTK+ version are you using?
I suspect that the version the reporter is using is not really the latest CVS. Mitch did a hackish workaround to solve this problem some days ago: 2004-02-02 Michael Natterer <mitch@gimp.org> * app/widgets/gimpimagedock.c (gimp_image_dock_constructor): also destroy the <Image> factory's "Tools" submenu because menu shortcuts with no or <shift> modifier prevent this key to be entered in text entries. This really badly baldy cries for GTK+ 2.4's GtkActions... Of course the problem still appears when a menu item outside <image>->Tools has a non-modifier shortcut and I can confirm that with current CVS.
Example (default configuration): Shift-Q toggles the quickmask, Shift-O does select-by-color, "1" switches to 1:1 instead of getting entered in the entry. Interestingly "+" and "-" work as expected despite being shortcuts. When we don't manage to ensure that text entries really have the focus I'd vote for removing the global shortcuts again.
*** Bug 133471 has been marked as a duplicate of this bug. ***
This needs to be addressed before 2.0. Perhaps while we don't have GtkActions it might be better to back out this change? Dave.
GtkActions won't help a single bit to resolve this. The actual problem is that all key events are handled by the window and the window processes its accel tables before dispatching the event to the widget which has the focus. It's questionable whether this logic should also apply to text entry widgets, but then there are valid use cases for both behaviours, and GTK+ went for invoking accels first (which is a good thing to do since GIMP's use of <shift> and "no modifier" accels is quite nonstandard). Which means we have to hack the desired behaviour ourselves and disable the window's accel_group while inline-editing in a GtkTreeView. This will have to wait until 2.2 because we need GtkCellRenderer's new "editing_canceled" signal.
So... what do we do? Not being able to type a bunch of characters is a fairly major issue - it makes dynamic shortcuts a problem issue. Is it enough to use the same trick on the View->Zoom, File, Edit, Layers, Dialogs, Filters and Selection menus? I just tested, and it seems that Shift-Q and Shift-O work OK, but user-assigned shortcuts in all those menus still get trapped. Alternatively, removing global shortcuts (which seems like more or less the same thing) until this is figured out at the gtk+ level (as both nomis & myself has suggested) might be an idea, if there isn't a short-term workaround. Cheers, Dave.
I agree that this is a fairly major issue, although there is a known workaround (docking/undocking the brush editor dialog from the toolbox) It would be nice if at least one of the following options could be implemented before 2.0: 1 - disable the accel_group while editing 2 - remove the global shortcuts 3 - pop up a new dialog without accelerators for editing brush names 4 - redesign all GIMP shortcuts and use Ctrl, Ctrl+Shift or Ctrl+Alt for all of them. Option 1 is only suitable for version 2.2, as Mitch mentioned above. Option 2 is easy to implement, but we have to compare the advantages of the global accelerators with the problems mentioned here. Option 3 would be an ugly hack, but it could be a temporary workaround that fixes this bug while preserving the global shortcuts. I don't know if this can be implemented easily, though. Option 4 is probably not reasonable.
Raphael, it is not only about editing brush names. It is also about editing layer names, entering numerical values into any numerical entry ('1' == 1:1!) etc. pp. So 3 would not just be *one* additional dialog but more like dozends and basically impossible to implement. 4 indeed is not an option. as for 1 mitch probably referred to GTK+ 2.4 (we already depend on GTK+-2.2), and I don't think that we want to depend on GTK+ 2.4 for GIMP 2.0. So 2 is the only option I see right now. And the problems discussed here definitely outweight the advantage of having global shortcuts.
Just a min. Would 2 disable the user-assigned shortcuts while on the Image window, or just when the focus is on the dialogs? Becaus if that is the case, I would not consider it as an option. Having to dig in four menu levels to get a tool one uses oftenly, instead of pressing a single key would cripple the GIMP beyond imagination. If they stop working just on the dialogs and dockables, it'd be ok. Why is (4) voted out so fast? It seens more reasonable than (2). Would it be that hard to get?
Don't worry, the shortcuts will work fine in the image window. Requiring the CTRL-modifier for shortcuts (we are not only talking about user-defined shortcuts here) is not an option, because that effectively kills about 50% of the possible shortcuts and makes about 75% of the remaining shortcuts more arkward to use (because you need to press one more modifier). People would be forced to completely relearn their shortcuts, e.g. people that used their number keys to quickly navigate between different zoom levels. This is a severe limitation and IMHO is not an option, especially when a feasible solution (1) is most probably available in some months.
So - mitch - do you think it's reasonable to temporarily roll back this feature? Cheers, Dave.
Fixed in CVS: 2004-03-04 Simon Budig <simon@gimp.org> * app/widgets/gimpimagedock.[ch]: #ifdef'ed the code for the global shortcuts and disabled it. Fixes bug #133453