Bug 766918

Ah - should have searched for this entry - instead of adding to #760875.

Encountered the same problem - and worked-arround with:

yum downgrade gtk3 gtk3-immodule-xim

i.e
working gtk3-3.2.1-1.fc16.x86_64
broken  gtk3-3.2.2-2.fc16.x86_64

+1 This workaround fixed things for me. I'd like to see a patch in the next version though.

IIUC from the upstream bug, that change in gtk was intentional, and just manifested a long-standing misuse of modifier masks in vte.

The updated vte3 is already in updates-testing (https://admin.fedoraproject.org/updates/FEDORA-2011-17004/vte3-0.30.1-3.fc16), and makes Alt work again in gnome-terminal.

Component may have been accidentally changed, resetting to gtk3 for now.

As Roman noted in comment#3, the vte3-0.30.1-3 update in 'updates-testing' resolves the reported problem.  Moving to MODIFIED.

$ rpm -q --changelog vte3 | head
* Mon Dec 12 2011 Matthias Clasen <mclasen> - 0.30.1-3
- Fix problems with Alt<>Meta with recent gtk

(In reply to comment #3)
> The updated vte3 is already in updates-testing

Thanks! updated vte3 from updates-testing fixes the issue for me.

I've also confirmed that the vte3 update worked:

$ rpm -q gtk3 vte3
gtk3-3.2.2-2.fc16.x86_64
vte3-0.30.1-3.fc16.x86_64

vte3 in updates-testing also worked for me.  The submitter of the bodhi update should add this bug to the bodhi update so we get automatic notification.   Also moving component to vte3, as that's the broken component.

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

OK, after this vte3 update, I'm able to roxterm with Alt key as meta. But still not for gnome-terminal!

mike@localhost% rpm -q gtk3 vte3 gnome-terminal roxterm
gtk3-3.2.2-4.fc16.x86_64
vte3-0.30.1-3.fc16.x86_64
gnome-terminal-3.2.1-2.fc16.x86_64
roxterm-1.21.2-1.fc16.x86_64

I also tried vte3's sample terminal, it works perfectly.  The only program that doesn't work with Alt key now it's gnome-terminal.

Sorry about the confusion of last post.  Just check out that roxterm in fedora is only gtk2 based, which has nothing to do with this bug.

Still, vte3's sample is able to use Alt key, but not for gnome-terminal.

(In reply to comment #11)
> Sorry about the confusion of last post.  Just check out that roxterm in fedora
> is only gtk2 based, which has nothing to do with this bug.
> 
> Still, vte3's sample is able to use Alt key, but not for gnome-terminal.

Did you logout and login again to your GNOME 3 session?  gnome-terminal works fine for me with the vte3 update.

(In reply to comment #12)
> (In reply to comment #11)
> > Sorry about the confusion of last post.  Just check out that roxterm in fedora
> > is only gtk2 based, which has nothing to do with this bug.
> > 
> > Still, vte3's sample is able to use Alt key, but not for gnome-terminal.
> 
> Did you logout and login again to your GNOME 3 session?  gnome-terminal works
> fine for me with the vte3 update.

Yes, I'm sure I did logout and login (and even with reboot).

My laptop is a X200, "System Settings" in GNOME3 show Meta_L is the same key as Alt_L key.  My locale is "en_US.utf8", and running with ibus.  But it's still the same effect when I use the "None" input method under gnome-terminal.

mike@localhost% xmodmap 
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock      
control     Control_L (0x25),  Control_L (0x42),  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)

(In reply to comment #13)

> Yes, I'm sure I did logout and login (and even with reboot).

Odd.

(In reply to comment #10)

> mike@localhost% rpm -q gtk3 vte3 gnome-terminal roxterm
> gtk3-3.2.2-4.fc16.x86_64
> vte3-0.30.1-3.fc16.x86_64
> gnome-terminal-3.2.1-2.fc16.x86_64
> roxterm-1.21.2-1.fc16.x86_64

The versions of those packages that do work for me are:

$ rpm -q gtk3 vte3 gnome-terminal 
gtk3-3.2.2-2.fc16.x86_64
vte3-0.30.1-3.fc16.x86_64
gnome-terminal-3.2.1-2.fc16.x86_64

I notice that I'm running a slightly older version of gtk3, I'll try to upgrade to the same version that you're running to see if I can reproduce your problem .

OK, updated to the following:

$ rpm -q gtk3 vte3 gnome-terminal 
gtk3-3.2.2-4.fc16.x86_64
vte3-0.30.1-3.fc16.x86_64
gnome-terminal-3.2.1-2.fc16.x86_64

In bash Alt-b and Alt-f (for example) in gnome-terminal works fine for me.

$ 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)

I'm using the "System (Simple)" input method option in gnome-terminal.

(In reply to comment #14)
> (In reply to comment #13)
> 
> > Yes, I'm sure I did logout and login (and even with reboot).
> 
> Odd.
> 
> (In reply to comment #10)
> 
> > mike@localhost% rpm -q gtk3 vte3 gnome-terminal roxterm
> > gtk3-3.2.2-4.fc16.x86_64
> > vte3-0.30.1-3.fc16.x86_64
> > gnome-terminal-3.2.1-2.fc16.x86_64
> > roxterm-1.21.2-1.fc16.x86_64
> 
> The versions of those packages that do work for me are:
> 
> $ rpm -q gtk3 vte3 gnome-terminal 
> gtk3-3.2.2-2.fc16.x86_64
> vte3-0.30.1-3.fc16.x86_64
> gnome-terminal-3.2.1-2.fc16.x86_64
> 
> I notice that I'm running a slightly older version of gtk3, I'll try to upgrade
> to the same version that you're running to see if I can reproduce your problem
> .

Sorry for the confusion.  I just figure out the problem just then.  yum reinstall only update the links of vte /usr/lib64/libvte2_90.so but not /usr/lib64/libvte2_90.so.9.  libvte2_90.so.9 was linked to an older version of vte3 on my laptop.  

Sorry.  Now I confirm this bug has been fixed for vte3.

Should never compile anything to /usr myself anymore! >.<

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.