After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 601863 - GTK+ should provide abstracted modifier masks
GTK+ should provide abstracted modifier masks
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.19.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 605799
 
 
Reported: 2009-11-14 01:24 UTC by Javier Jardón (IRC: jjardon)
Modified: 2011-09-28 20:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Javier Jardón (IRC: jjardon) 2009-11-14 01:24:48 UTC
From a comment by Paul Davis here: https://bugzilla.gnome.org/show_bug.cgi?id=530351#c18

"as mentioned on IRC with mitch and matthias, GTK should really provide abstracted modifier masks"..."(GTK+) doesn't provide any standard way
for GTK applications (and it *is* a toolkit) to determine the right modifiers
to be using given the platform"..."applications still end up using CONTROL, MOD1 etc with no standard platform-sensitive scheme"
Comment 1 jessevdk@gmail.com 2009-12-31 11:24:08 UTC
Any news on this? I think this should be pretty simple patch (see referenced bug #530351), we would like to see this be applied (for example for gedit) to get rid of custom code/gtkrc files to set the correct modifier keys. Are there any reasons to not apply it, or is it just a matter of supplying a clean patch?
Comment 2 Paul Davis 2010-01-15 19:18:04 UTC
its not a simple patch. applications need to have access to GDK_PRIMARY_MODIFIER rather than, say, GDK_CONTROL_MASK, and the value of the mask needs to be set appropriately for the platform. The available abstract modifiers also need to capture the subtlety of default modifiers too. For example, when using modifiers to change a current selection by extending it with a mouse click, I think its conventional to use Shift-click. This is use of Shift in a semantically different way than when using it as a keyboard shortcut. This implies that one would need GDK_EXTEND_SELECTION_MODIFIER in addition to GDK_????_MODIFIER that refers to Shift on a given platform.
Comment 3 Phillip Heller 2010-08-26 16:35:12 UTC
Just wanted to add my impact to this bug.  I've added gtk_osxapplication based menu integration to a pygtk application.  The menu accelerators initially used the CONTROL modifier, which I adjust to META when the application is run on a mac.

However, there is then some collision between the menu accelerators and gtk stock button accelerators (i.e., CMD-"O" for "Open Form" collides with "OK" in a dialog using stock "gtk-ok", where the modifier for the latter should be Alt, but is Cmd due to this bug)
Comment 4 Michael Natterer 2011-09-28 20:34:56 UTC
enum GdkModifierIntent and gdk_keymap_get_modifier_mask(intent) have
just landed in GTK+ master.