GNOME Bugzilla – Bug 624572
Can't drag panel when mouse modifier is set to <Super> key
Last modified: 2020-11-06 20:23:31 UTC
Created attachment 166042 [details] [review] map virtual modifiers backward to their real counterparts Red Hat has a customer that maps window management functions to the "windows" key on their keyboards via metacity's gconf key. gnome-panel now piggy-backs off that gconf key, but it only works for "real" modifiers. It doesn't seem to properly handle virtual modifiers like the windows key.
*** Bug 569162 has been marked as a duplicate of this bug. ***
Review of attachment 166042 [details] [review]: Thanks for investigating this issue! I'm assuming it all works fine, etc. I'm wondering, though, shouldn't GDK do this for us? It sounds weird that all apps wanting to do something similar would have to deal with this. ::: gnome-panel/panel-toplevel.c @@ +3260,3 @@ * only have the handles that the user can grab. */ if ((toplevel->priv->expand || toplevel->priv->attached) && + (event->state & GDK_MODIFIER_MASK) != panel_bindings_get_mouse_button_modifier_keymask ()) Can you tell why this is needed? (You're probably right; I'm just curious) ::: gnome-panel/panel-xutils.c @@ +214,3 @@ + * empty entries. Filter those out + * (along with any invalid entries) + */ Nitpicking: Can you close the comment at the end of the previous line?
Oh, and if there's a good reason that we have to do this in the panel, please go ahead and commit to master (and any branch where it's needed for you).
(In reply to comment #2) > Review of attachment 166042 [details] [review]: > > Thanks for investigating this issue! I'm assuming it all works fine, etc. I'm > wondering, though, shouldn't GDK do this for us? It sounds weird that all apps > wanting to do something similar would have to deal with this. So I dove into this a bit after reading the above, and it looks like gtk was changed to do that here: http://git.gnome.org/browse/gtk+/commit/?id=03b179c5e8311591f1487a650fec6f20a136e9ca but was reverted here: http://git.gnome.org/browse/gtk+/commit/?id=13d69e552dffe681ee80c0600366a8c04fc205c6 because of compat problems. It looks like there is a convenience function now though, gdk_keymap_add_virtual_modifiers (). We can't use that on the gnome-2-30 branch, but could use it in master. > > ::: gnome-panel/panel-toplevel.c > @@ +3260,3 @@ > * only have the handles that the user can grab. */ > if ((toplevel->priv->expand || toplevel->priv->attached) && > + (event->state & GDK_MODIFIER_MASK) != > panel_bindings_get_mouse_button_modifier_keymask ()) > > Can you tell why this is needed? (You're probably right; I'm just curious) For some reason the above excerpt is missing something like - (event->state & gtk_accelerator_get_default_mod_mask ()) != which is in the patch. gtk_accelerator_get_default_mod_mask () doesn't include Mod2-Mod5 by default. > > ::: gnome-panel/panel-xutils.c > @@ +214,3 @@ > + * empty entries. Filter those out > + * (along with any invalid entries) > + */ > > Nitpicking: Can you close the comment at the end of the previous line? Sure.
Comment on attachment 166042 [details] [review] map virtual modifiers backward to their real counterparts Committed now. I'm leaving the bug open, because I think we can change master to use the new gtk function.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.