You pasted me this commit in private mail:

http://git.gnome.org/browse/vte/commit/?id=b73782a28894e25ed146271f9d6c6775a6836199

This definitely can't work any longer for the common PC keyboard layout
that has MOD1 mapped to META. Pressing Alt will now always produce MOD1
and nothing else, because that's what all of GTK+ expects.

My commit from above essentially nails Alt == MOD1 and nothing else.

I don't think this can be fixed in GTK+. If you want Alt, use GDK_MOD1_MASK,
not META (which could also be mapped to whatever key).

I’ve tried the reverse of Behdad’s patch now (i.e., what was initially intended and then reverted) and it works now.

Maybe what Michael changed in GTK now is what was missing the last time?

I obviously don’t have a good grasp of what is going on and most of my last comment is wrong.

But it works when hardcoding Alt to Meta again, which is a truism. I’m not sure what the people with exotic layouts in the original bug say about that.

I'm in fact clueless as to what these should be.  Someone should check with the bug I was trying to fix.  There was legitimate reason for that change at the time.

And from the vte point of view, "whatever xterm does" is the right behavior.

*** Bug 663917 has been marked as a duplicate of this bug. ***

I am sure that if you want Alt, you use GDK_MOD1_MASK. GDK_META_MASK
is not going to work any longer.

Essentially, they way VTE seems to map META to some key is totally broken.

META is not a key, it's a virtual modifier that can be on any of
MOD1..MOD4, and with the recent changes in GTK+ it can only work
if it is on one of MOD2..MOD4 because we now consistently treat
MOD1 as ALT, and took it out of the virtual modifier mapping.

Created attachment 201423 [details] [review]
proposed patch

This patch maps gdk's Meta and Alt both to vte's Meta. It should allow both people with standard PC keymaps and those who are using strange custom mappings (like in bug #601926) to use their favorite meta key in vte. In particular, it unbreaks vte Alt handling with gtk+-3.2.2.

Confirmed that Alexandre's patch works for me, too. Thanks!

There seems to be a little catch though.

While I'm not completely sure it's caused by this change, I have following problem:

in midnight commander (how many of you (still) use it ?), while i.e. alt-h works, alt-? (so alt-shift-/) doesn't.

I'm not sure (yet) if it's the -shift- part that matters.

I'm on Gentoo and already using patch from comment 9.

(In reply to comment #11)
> There seems to be a little catch though.
> 
> While I'm not completely sure it's caused by this change, I have following
> problem:
> 
> in midnight commander (how many of you (still) use it ?), while i.e. alt-h
> works, alt-? (so alt-shift-/) doesn't.

Observations:

1. With my vte patch and gtk+-3.2.2, alt-! (i.e. alt-shift-1) works correctly in mc.
2. With my vte patch and gtk+-3.2.1, alt-/ and alt-? (i.e. alt-shift-/) both work correctly in mc.
3. With my vte patch and gtk+-3.2.2, alt-/ and alt-? both fail in mc.

Created attachment 201649 [details] [review]
proposed patch (second attempt)

The problem with my first patch is that two functions in keymap.c (_vte_keymap_map and _vte_keymap_key_add_key_modifiers) in effect compared VTE_META_MASK to gdk key modifier by numerical equality, but since my patch made VTE_META_MASK into a compound mask, such comparison was no longer guaranteed to work.

The possible solutions were to either (1) rewrite parts of keymap.c to treat GDK_META_MASK separately fro GDK_MOD1_MASK; or (2) to introduce a new function to fix up gdk modifiers by ensuring that if any VTE_META_MASK bits are set, then all are set, which in effect again results in VTE_META_MASK being treated an indivisible mask.

I chose option (2) because it seemed simpler and much less likely to introduce errors.

With this patch, all shortcuts in midnight commander work correctly :)

Again, if you really want META, then you cannot define it as constant,
because it isn't.

If you want ALT, use MOD1 mask.

If you *really* want META, take GDK_META_MASK and run it through
gdk_keymap_map_virtual_modifiers(), then check what bit was added,
the added bit will be in the range of MOD2...MOD5, but with latest
GTK+ it will *never* be MOD1.

Also, latest GTK+ will *never* give you GDK_META_MASK if META is colocated
with ALT and used to be triggered by MOD1.

(In reply to comment #14)
> Again, if you really want META, then you cannot define it as constant,
> because it isn't.
> 
> If you want ALT, use MOD1 mask.
> 
> If you *really* want META, take GDK_META_MASK and run it through
> gdk_keymap_map_virtual_modifiers(), then check what bit was added,
> the added bit will be in the range of MOD2...MOD5, but with latest
> GTK+ it will *never* be MOD1.
> 
> Also, latest GTK+ will *never* give you GDK_META_MASK if META is colocated
> with ALT and used to be triggered by MOD1.

Michael, the issue is that gtk's and a terminal's concepts of Meta do not match.

The gtk world is oriented towards modern PC hardware. "Normal" gtk applications are just expected to use MOD1, better known as Alt. And Meta is an alias for something weird in the MOD2..MOD5 range (formerly MOD1..MOD5), reserved for people with unusual tastes in keyboards.

By contrast, the terminal world is oriented towards old Unix machines. "Normal" terminal applications don't know about this new-fangled thing called "Alt". They know about "Meta", which they assume is a physical key like on the old Sun keyboards. Users of lesser keyboards are expected to assign a key (or maybe several keys) to output the Meta modifier.

And vte lives on the boundary between the gtk world and the terminal world. It needs to take keyboard input from gtk and transform it into terminal codes. And it must deal with users, some of whom expect Alt on their keyboard to correspond to Meta in their terminal, and others who expect the Windows key on their keyboard to correspond to Meta in the terminal.

tl;dr version: VTE_META_MASK != GDK_META_MASK, and for a good reason.

Ok, so I'm an end-user, I'm using a vte based GTK (2) terminal, and I can't use my Alt key anymore. Aiui same thing will (or already does) happen to people using vte3 based terminals.

I'm not sure if the problem lies in GTK+ or in vte (and I don't really care), but could we have the previous behavior back?

Alexandre, I understand completely. I'm just saying is that if you
want META to work, you have to use the right GTK+ API to figure where
it is. You would have to do exactly the same, only much more complicated,
with plain X11.

This has nothing to do with GTK+ having a different focus than good old
terminals where users expect Meta. Even if there is a Mata key on your
keyboard, you have to map MODn using the right API in order to figure
if Meta is pressed or not.

Users don't expect Alt to be Meta, they expect the terminal to do the right
thing whether or not they have Meta on Alt, or mapped it around to e.g.
the Windows key on purpose.

You can't hardcode it. And with latest GTK+ you need to special case
Alt == Meta *if* gdk_keymap_map_virtual_modifiers() fails to map
it to any of MOD2..MOD4.

I can't see from the attached patch if any part of vte calls the opposite
function gdk_keymap_add_virtual_modifiers(), but if it does, you are
probably fine with (MOD1 | META), otherwise you aren't.

(In reply to comment #17)

Thanks for the explanation!

> I can't see from the attached patch if any part of vte calls the opposite
> function gdk_keymap_add_virtual_modifiers(), but if it does, you are
> probably fine with (MOD1 | META), otherwise you aren't.

Vte calls gdk_keymap_add_virtual_modifiers() in vte_terminal_read_modifiers(), which is the function that extracts key modifiers from a GdkEvent. So using MOD1|META should be fine.

This bug is affecting Fedora 16 users in both vte3 (for gnome-terminal) and vte (for roxterm and XFCE Terminal, possibly others). I think Alexandre's comment #18 means that the proposed patch should be applied. Is that right?

I'm on fully updated Fedora 16 with the following package versions:

vte-0.28.1-1.fc16.x86_64
gtk2-2.24.8-2.fc16.x86_64
Terminal-0.4.8-1.fc16.x86_64

This is the XFCE terminal in gtk2 land.

Noticed that with the recent gtk2 update, Emacs (-nw, i.e, console mode) meta key was not working, and alt was generally broken when using it to switch tabs in irssi. Upon searching and following a Debian bug, I arrived here.

I confirm that with the vte patch in comment #13, things work as normal again.

*** Bug 665386 has been marked as a duplicate of this bug. ***

I'm finding there's still a problem with the vte patch in comment #13. I'm testing using the rpms from http://thm.fedorapeople.org/vte/ which include this patch. The Alt key works as expected now in XFCE Terminal and roxterm.

However the Windows key isn't working as it did prior to the gtk change. Attempting to bind win-t to open a new tab in XFCE Terminal results in the binding "<Mod4><Super>t" but it doesn't actually work. Instead "t" appears in the current terminal window.  I've tried various other incantations of "<Mod4>t" and "<Super>t" by editing the config file directly to no avail. Do we need another vte patch for this, or does something else need to change?

(In reply to comment #22)
> However the Windows key isn't working as it did prior to the gtk change.
> Attempting to bind win-t to open a new tab in XFCE Terminal results in the
> binding "<Mod4><Super>t" but it doesn't actually work. Instead "t" appears in
> the current terminal window.  I've tried various other incantations of
> "<Mod4>t" and "<Super>t" by editing the config file directly to no avail. Do we
> need another vte patch for this, or does something else need to change?

In Gentoo, I can reproduce this behavior with xfce terminal 0.4.8 both "prior to the change" (i.e. with gtk+-2.24.7 and unpatched gtk2-based vte-0.28.2) and "after the change" (i.e. with gtk+-2.24.8 and patched gtk2-based vte-0.28.2).

In other words, as far as I can tell, the vte terminal shortcuts Windows key handling quirk is not related to the gtk's Alt key handling change or to the vte patch in comment #13.

(In reply to comment #23)
> In other words, as far as I can tell, the vte terminal shortcuts handling

Typo: s/vte terminal/xfce terminal/

(In reply to comment #22)
> I'm finding there's still a problem with the vte patch in comment #13. I'm
> testing using the rpms from http://thm.fedorapeople.org/vte/ which include this
> patch. The Alt key works as expected now in XFCE Terminal and roxterm.
> 
> However the Windows key isn't working as it did prior to the gtk change.
> Attempting to bind win-t to open a new tab in XFCE Terminal results in the
> binding "<Mod4><Super>t" but it doesn't actually work. Instead "t" appears in
> the current terminal window.  I've tried various other incantations of
> "<Mod4>t" and "<Super>t" by editing the config file directly to no avail. Do we
> need another vte patch for this, or does something else need to change?

Can you show the output of xmodmap ?

(In reply to comment #25)
> Can you show the output of xmodmap ?

Hi Matthias, thanks for taking an interest. Here's the output of xmodmap:

 xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):
 
 shift       Shift_L (0x32),  Shift_R (0x3e)
 lock        Caps_Lock (0x42)
 control     Control_L (0x25),  Control_R (0x69)
 mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
 mod2        Num_Lock (0x4d)
 mod3      
 mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
 mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

For a specific keybinding example, I have Super+t bound to create a new tab. This works in Fedora 15 in all of XFCE Terminal, roxterm and gnome-terminal. So it works for both gtk2 and gtk3. But it doesn't work in Fedora 16.

However I've done more experimentation, and here's what I've found:

 F15 twm + gnome-terminal WORKS
 F15 kwin + gnome-terminal WORKS
 F15 GNOME + gnome-terminal WORKS
 F15 KDE + gnome-terminal WORKS

 F16 twm + gnome-terminal WORKS
 F16 kwin + gnome-terminal WORKS
 F16 GNOME + gnome-terminal DOESN'T WORK
 F16 KDE + gnome-terminal DOESN'T WORK

In other words, the only time it doesn't work is when I have a full desktop environment running, either GNOME or KDE. However the xmodmap output never changes. It's always exactly what I pasted above, in all of the environments.

I realize this is now completely separate from the issue in this ticket. Please follow up to me personally (agriffis@n01se.net) if you have suggestions or let me know if I should open a new ticket. Thanks!

And just to clarify: 'WORKS/DOESN'T WORK' here refers to <Super>t triggering the configured action, or to editing the keybinding working as intended, or a combination or both ?

(In reply to comment #27)
> And just to clarify: 'WORKS/DOESN'T WORK' here refers to <Super>t triggering
> the configured action, or to editing the keybinding working as intended, or a
> combination or both ?

I was referring to the triggering of the configured action. However attempting to edit the keybinding in gnome-terminal reveals something:

 F16 GNOME gnome-terminal keybinding attempt yields "Super+Hyper+T"
 ("<Hyper><Super>t" in gconf). The action doesn't work, instead I get
 "t" in the terminal window. Changing it in gconf to either "<Super>t"
 or "<Hyper>t" doesn't change the behavior.

 F16 twm gnome-terminal keybinding attempt yields the same
 "Super+Hyper+T" ("<Hyper><Super>t" in gconf). Just like running
 GNOME, the action doesn't work, instead I get "t" in the terminal
 window. HOWEVER in this case, changing it in gconf to "<Super>t" or
 "<Hyper>t" (either one) results in a working keybinding!

So in other words, the keybinding dialog doesn't result in a working binding in either GNOME or bare twm. However it is possible to manually get a working binding in twm, whereas it is impossible to get a working binding in GNOME.

Matthias, does any of this make sense to you? It's a frustrating mystery to me, especially since xmodmap doesn't show any differences between running with/without the GNOME environment.

I should add that on F15, the Keyboard Shortcuts dialog yields "Super+T" (instead of "Super+Hyper+T" which seems broken on F16).  Additionally, as mentioned previously, the actions work on F15 in both GNOME and KDE.

(In reply to comment #28)

> Matthias, does any of this make sense to you? It's a frustrating mystery to me,
> especially since xmodmap doesn't show any differences between running
> with/without the GNOME environment.

Yes, thanks. I think we have a pretty good idea whats going wrong here.

(In reply to comment #30)
> (In reply to comment #28)
> 
> > Matthias, does any of this make sense to you? It's a frustrating mystery to me,
> > especially since xmodmap doesn't show any differences between running
> > with/without the GNOME environment.
> 
> Yes, thanks. I think we have a pretty good idea whats going wrong here.

That sounds encouraging. :-)  Can you explain in a nutshell?

*** Bug 666055 has been marked as a duplicate of this bug. ***

(In reply to comment #31)

> That sounds encouraging. :-)  Can you explain in a nutshell?

http://git.gnome.org/browse/gtk+/commit/?id=9bf17a95e57dd0d223cf45e5e7332b7ef04134b7

Does that gtk commit fix vte, or is there any vte patch still required?

the vte patch is still required

the gtk commit fixes the accel cell renderer, ie accel editing in gnome-terminal

(In reply to comment #34)
> Does that gtk commit fix vte, or is there any vte patch still required?

any news about including this fix into 0.32.1? since you just released 0.32 without including this fix.

Comment on attachment 201649 [details] [review]
proposed patch (second attempt)

I don't like this approach. The keymap handling should be left alone.

Instead, the modifiers should be mangled as they come out of the GdkEvent, ie. in vte_terminal_read_modifiers(). There, map to VTE_META_MASK whatever modifiers should map to it; perhaps as simple as testing GDK_META_MASK | GD_MOD1_MASK, or possibly as sophisticated as comment 14 suggests.

Created attachment 213924 [details] [review]
keymap: Treat ALT as META

Comment on attachment 213924 [details] [review]
keymap: Treat ALT as META

Pushed to vte-0-32 and vte-next.

Keeping this bug open because I'm not sure yet that this is in fact the best fix possible.

[Patch committed, removing GNOME target.]

Created attachment 242449 [details] [review]
alt-meta.patch

We are still carrying this patch downstream on Gentoo, not sure if it could be reviewed for inclusion :/