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 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 +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