Control/Alt key bindings are broken in GTK 3 programs using gtkbuilder

It seems to only affect GTK applications. Qt apps and XUL apps do not exhibit the issue.

Only application I can reproduce with is chromium

Indeed, as Chromium as a particular menu, I would say this is fixed. Can someone on the unity-2d team confirmed it's fixed as well?

Nope, for me it's still here in GTK apps.

I can also reproduce it in gedit, in Unity 2D. I'll investigate the issue in my spare time -- but if someone gets free and can commit more time to it, feel free to take the bug from me. :-)

Under Unity 2D, this happens for Qt apps as well -- though somehow differently: with Qt assistant, Alt+F works only every other time; or, if you keep the Alt key pressed, you need to press "F" *twice* in order to bring up the menu.

didrocks and pitti pointed me at this bug, which probably causes problems i've seen in gtimelog 0.6.1. It's not just Alt that gets eaten, but also ctrl-q, ctrl-e, ctrl-r, and ctrl-d (essentially all alt- and ctrl- accelerators defined for the app). I was confused because running it from lp:gtimelog worked fine, but a package built from the same source did not work. pitti then reminded me of debian/patches/force-gi which, as should be obvious, forces gi. Without that package-only patch, pygtk is used and everything works.

Is this a Gtk 2.0 vs Gtk 3.0 issue? For me, all the Gtk 3.0 apps are broken, but Gtk 2.0 apps work fine. If someone can confirm, then we can investigate the Gtk 3.0 plugin.

confirming, only gtk 3.0 apps are impacted.

Yes, this is definitely the case, adding indicator-appmenu

The Alt+<menu letter> part was fixed in bug 821290. However, Ctrl keybindings still remain broken, retitling accordingly.

From what I can observe, the ctrl bindings work correctly for me in GTK 3 programs. At least on 3.1.92-0ubuntu1 of gtk3.

Łukasz Zemczak [2011-10-04 8:33 -0000]:
> From what I can observe, the ctrl bindings work correctly for me in GTK
> 3 programs. At least on 3.1.92-0ubuntu1 of gtk3.

Right, they work again in nautilus etc., but e. g. not in gtimelog.

Yeah, I can confirm problems with gtimelog, but it doesn't look GTK3?

Michał Sawicz [2011-10-04 9:02 -0000]:
> Yeah, I can confirm problems with gtimelog, but it doesn't look GTK3?

It is, through PyGI (from gi.repository import Gtk).

Single key shortcuts don't work too. Like 'L' or 'F' in audacious from this PPA: https://launchpad.net/~nilarimogard/+archive/webupd8

This should be fixed with gtk3 patch related to bug #821290 isn't it?

No, sorry. I'm wrong.

This actually seems an issue related to gtkBuilder... In fact also this example that I've written in vala using the gtimeline UI has the exactly same issue: http://paste.ubuntu.com/706261/

gcalctool has similar issues, i.e ctrl-Q for an example doesn't work

Ted, that's still an issue, could you look at ti?

I've actually looked at the entire stack from unity-panel-service to libgtk and I can't notice any difference in how a standard menubar is initalized, compared to an one using gtkbuilder.

The only difference is that the initialization of the gtk accelerators for a gtkbuilder menubar is done in _gtk_widget_buildable_finish_accelerator() but that performs the exactly same operations that we should have done by hand.

So, I've added some debug bits to dbusmenu, indicator-appmenu, appmenu-gtk and libgtk... If I run the sample code linked above, I get this output: http://paste.ubuntu.com/707116/
As you can see gtk correctly initializes the accelerators and libdbusmenu-gtk exports them correclty.

On the other side, and so in unity-panel-service the output of my debug session is http://paste.ubuntu.com/707114/ and it actually shows how correctly the application registers its accelerators as dbusmenuitems.

So I can't find what's exactly going on here. For sure the isse with a gtkbuilder-based application accelerators stop to work when the gtk-menubar his hidden. In fact if you edit the gtk's file gtkmenubar.c and you add at the end of local_notify something like:
 GTK_WIDGET_CLASS (gtk_menu_bar_parent_class)->show (GTK_WIDGET (widget));
to make it always show the menubar (also if collapsed), then the accelerators will work also in a gtkbuilder application, but this is maybe quite obvious.

I could also attach the same logs (maybe improved, including the called function name) for a working application, but they don't seem to change compared to the above session.

Status changed to 'Confirmed' because the bug affects multiple users.

Ok, I've made some more testing and I've also found a solution, but before checking if that's right let's discuss a little.

Basically the issue we're always reproducing when using a gtkbuilder-based app, can also happening when manually programming our interface and basically when we're doing something like this in our menu widgets tree:
 - GtkMenubar { GtkMenuItem { GtkMenu { GtkMenuItem } } }

In this case, the inner GtkMenuItem won't be sensible to accelerators.
You can see a test example here: https://gist.github.com/1288553#file_badunitymenus_std.vala

GtkBuilder seems to use a structure like this one every time (and I also guess that gcalctool uses that too), and this cause the menu items not to be sensible to our accelerator keys.

Now, the possible solutions, everything here seems to start from gtkmenuitem.c's gtk_menu_item_can_activate_accel which checks if the parent widgets can manage an accelerator.
When using the ubuntu menubar the process stops returning false, due to the fact that the GtkMenuBar isn't drawn and so isn't activable according to gtk_widget_can_activate_accel(). So we have some possible solution:
 - In gtk_menu_item_can_activate_accel we just try to go back to all the parent widgets, just checking if they are sensitive
 - In gtk_menu_item_can_activate_accel we check if the parent widget is a GtkMenuBar and in the case, if it's sensitive we just skip it, and we pass to its own parent
 - override the can_activate_accel function in the class GtkMenuBar making that check only if the menu bar is sensitive.

The last one is of course the best one solution imho, and so I think that's the one I'll propose as soon as I can...

I think we must definitely fix this issue, since it could happen to all the apps not designed as we figured until now.

Finally, looking for this I also found another issue: if someone programmatically wants to hide a menubar, it's not possible in ubuntu. I guess we should track the show hide/status of that widget and check that to export the menu or not or to restore the visibility status when the menus are shown again as standard menus.

PS: from my tests this doesn't seem to affect gtk+2.0 programs, can you confirm this?

Hello Didier, or anyone else affected,

Accepted gtk+3.0 into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I tested the updated GTK+3.0 with gtimelog and simple-scan, the two programs where I noticed the broken keybindings every day. Both work fine now, thanks!

This bug was fixed in the package gtk+3.0 - 3.2.0-0ubuntu3

---------------
gtk+3.0 (3.2.0-0ubuntu3) oneiric-proposed; urgency=low

  * debian/patches/043_ubuntu_menu_proxy.patch: Fix menu accelerator
    support for UI generated with GtkBuilder or using GtkMenus
    submenus. Instead of using the gtk_widget_get_visible() function
    we check for the internal shown variable as it represents the
    real state (LP: #849732)
 -- Marco Trevisan (Trevino) <email address hidden> Sat, 15 Oct 2011 04:44:23 +0200