Exclude MOD1 from the virtual modifier mapping
Hi all,
as a fallout of the recent cross-platform modifier
key fixes that make Quartz work, it seems I broke
modifiers on X11.
The problem is that by enabling virtual modifiers
(META, SUPER, HYPER) in GtkCellRendererAccel, they
are now actually used :) which means that on a default
PC keyboard keymap on X11, which maps MOD1 to META,
entering Alt+foo now results in Alt+Meta+foo.
Now almost all of GTK+ treats MOD1 as ALT, they
are actually synonyms. I propose to simply go through
with this definition, and exclude MOD1 from any
mapping, such as SHIFT and CONTROL aren't mappable
to virtual either. This would nail down the MOD1 == ALT
mapping that is so far only done by *alnmost* all
the code in GTK+, which is inconsistent.
See attached patch, please comment.
Regards,
--Mitch
diff --git a/gdk/x11/gdkkeys-x11.c b/gdk/x11/gdkkeys-x11.c
index 5b7295b..80bf711 100644
--- a/gdk/x11/gdkkeys-x11.c
+++ b/gdk/x11/gdkkeys-x11.c
@@ -1489,13 +1489,12 @@ _gdk_x11_keymap_add_virt_mods (GdkKeymap *keymap,
keymap = GET_EFFECTIVE_KEYMAP (keymap);
keymap_x11 = GDK_X11_KEYMAP (keymap);
- for (i = 3; i 8; i++)
+ /* See comment in add_virtual_modifiers() */
+ for (i = 4; i 8; i++)
{
if ((1 i) *modifiers)
{
- if (keymap_x11-modmap[i] GDK_MOD1_MASK)
-*modifiers |= GDK_MOD1_MASK;
- else if (keymap_x11-modmap[i] GDK_SUPER_MASK)
+ if (keymap_x11-modmap[i] GDK_SUPER_MASK)
*modifiers |= GDK_SUPER_MASK;
else if (keymap_x11-modmap[i] GDK_HYPER_MASK)
*modifiers |= GDK_HYPER_MASK;
@@ -1515,12 +1514,16 @@ gdk_x11_keymap_add_virtual_modifiers (GdkKeymap *keymap,
keymap = GET_EFFECTIVE_KEYMAP (keymap);
keymap_x11 = GDK_X11_KEYMAP (keymap);
- for (i = 3; i 8; i++)
+ /* This loop used to start at 3, which included MOD1 in the
+ * virtual mapping. However, all of GTK+ treats MOD1 as a
+ * synonym for Alt, and does not expect it to be mapped around,
+ * therefore it's more sane to simply treat MOD1 like SHIFT and
+ * CONTROL, which are not mappable either.
+ */
+ for (i = 4; i 8; i++)
{
if ((1 i) *state)
{
- if (keymap_x11-modmap[i] GDK_MOD1_MASK)
-*state |= GDK_MOD1_MASK;
if (keymap_x11-modmap[i] GDK_SUPER_MASK)
*state |= GDK_SUPER_MASK;
if (keymap_x11-modmap[i] GDK_HYPER_MASK)
@@ -1589,7 +1592,8 @@ gdk_x11_keymap_map_virtual_modifiers (GdkKeymap *keymap,
{
if (*state vmods[j])
{
- for (i = 3; i 8; i++)
+ /* See comment in add_virtual_modifiers() */
+ for (i = 4; i 8; i++)
{
if (keymap_x11-modmap[i] vmods[j])
{
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Exclude MOD1 from the virtual modifier mapping
On Tue, Oct 25, 2011 at 9:46 AM, Michael Natterer mi...@gimp.org wrote: Hi all, as a fallout of the recent cross-platform modifier key fixes that make Quartz work, it seems I broke modifiers on X11. The problem is that by enabling virtual modifiers (META, SUPER, HYPER) in GtkCellRendererAccel, they are now actually used :) which means that on a default PC keyboard keymap on X11, which maps MOD1 to META, entering Alt+foo now results in Alt+Meta+foo. Now almost all of GTK+ treats MOD1 as ALT, they are actually synonyms. I propose to simply go through with this definition, and exclude MOD1 from any mapping, such as SHIFT and CONTROL aren't mappable to virtual either. This would nail down the MOD1 == ALT mapping that is so far only done by *alnmost* all the code in GTK+, which is inconsistent. See attached patch, please comment. Just to clarify, what we loose with this patch is the ability to have an Alt+x key combination match an accelerator of Meta+x, in the common case where Meta is colocated with Alt on mod1. I don't think this is a huge loss; I don't think there's a lot of accelerators involving Meta, Super or Hyper out in the wild - if only because GTK+ didn't use to include these in its accelerator mask until a few years ago. So, I am tentatively in favor of this change. We might even consider introducing a GDK_ALT_MASK to clarify the status of Alt. Another thing that needs cleanup is the duplication between gdk_keymap_add_virtual_mods and _gdk_keymap_add_virt_mods. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: regarding GIO
On Thu, 2011-10-20 at 10:27 -0400, Daniel Hernandez Bahr wrote: The thing is the GCancellable objects provide, as I am aware of, only the 'cancel' feature for async operations, would it be too hurtful to implement a GControllable class providing features such as 'pause'/'resume' as well as 'cancel' and maybe some other I fail to recall right now?? GIO is slightly lower-level than that. It just provides an abstraction for asynchronous I/O operations with cancellation. If you want to pause/resume transfers, you'll have to implement them yourself on top of that - you probably cannot use the predefined g_file_copy_async() and friends, but rather you'll have to do your own versions. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
Things to test are: everything related to menu behaviour (rich in grabs), everything involving press-and-hold-down mouse button behaviour, checking that the right things prelight as you move between windows and widgets. However, this is also more of a call for feedback about places where the current Gtk 2.24 code fails for you on windows. I'd like to know so i can try fixing it. See https://bugzilla.gnome.org/show_bug.cgi?id=646930 for an example of a regression in 2.24 wrt grabs. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
See https://bugzilla.gnome.org/show_bug.cgi?id=646930 for an example of a regression in 2.24 wrt grabs. I replied to this bug, it should be fixed already on the branch. Great, thanks for having a look! BTW, what's your estimate on looking at Gtk+ 3.x? Since 3.2 is now out, it would be great to have a stable 3.2 Gtk+ under Windows. Do you know about the status of 3.2 under Windows these days? Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
I want to make sure 2.24 works well first, then I will look at porting the fixes to master (and then back to 3.2 branch which should be trivial). The forward port should be mostly mechanic and not a lot of work, as there has not been a lot of conceptual changes to the gdk code. Makes sense, sounds promising. The one problematic thing for 3.x is the windows theme. That requires a completely different approach (to integrate with the css) which will require some new work. I see. Good to know, since the Windows theme is really a must have to have nicely integrated Gtk+ apps under Windows in our (AdaCore) experience. Thanks again for your work on this, much appreciated! Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
