dx-packages team mailing list archive

[Sebastien Bacher <seb128@xxxxxxxxxx>]

The issue is fixed in trusty:
https://launchpad.net/ubuntu/+source/indicator-appmenu/13.01.0+14.04.20131125-0ubuntu1

** Changed in: indicator-appmenu (Ubuntu)
       Status: Fix Committed => Fix Released

** Changed in: indicator-appmenu
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to indicator-appmenu in Ubuntu.
Matching subscriptions: dx-packages
https://bugs.launchpad.net/bugs/1191345

Title:
  all menu items are disabled with GTK 3.9.2

Status in The Application Menu:
  Fix Released
Status in “indicator-appmenu” package in Ubuntu:
  Fix Released

Bug description:
  When I run indicator-appmenu with GTK 3.9.2, all menu items are always
  disabled.  I used git bisect and found that this broke with this GTK
  commit:

  https://git.gnome.org/browse/gtk+/commit/?id=a4276a6c7959854e0654791e0cfdcca5b82ec213
  === 
  author	Ryan Lortie <desrt@xxxxxxxx>	2013-05-08 12:20:23 (GMT)
  commit	a4276a6c7959854e0654791e0cfdcca5b82ec213 

  add GtkMenuTrackerItem

  Add a new class, GtkMenuTrackerItem that represents a menu item, to be
  used with GtkMenuTracker.

  GtkMenuTracker's insert callback now works in terms of this new type
  (instead of passing reference to the model and an index to the item).
  ...
  ===

  Ryan sent the following thoughts about this by email:

  ===
  I have a theory: this patch introduced a major optimisation: it uses the
  GtkActionMuxer from the root of the menu rather than forcing an action
  muxer into existence for each submenu and menu item.

  From what I recall, the way that we insert action groups into the menus
  from the unity appmenu indicator is a bit.... "weird".  It's done this
  way because of how the architecture of the panel is structured -- you're
  not actually creating a GtkMenuBar, but rather a list of Indicator
  objects which have individual menu items hanging off of them.  The code
  inside of the panel service is taking a GtkMenuBar constructed by GTK
  and ripping it apart and inserting menus into these indicator objects.

  Back in the day, this ripping apart was causing problems: the menus lost
  linkage with the menubar that defined them and therefore adding action
  groups to that menubar itself was a no-go: each menu had to have the
  action group added directly.

  Now that the individual menu items are now getting their actions
  provided to them via the actionmuxer on the main menubar despite any
  ripping-apart that we may do later, we probably should just change to
  inserting the action groups directly onto the toplevel menubar itself. 
  I bet doing so would fix this issue (and be an additional optimisation)

  TL;DR: you're seeing the unity panel service doing some vaguely
  undefined behaviour (modifying a menu created by a binding) and
  suffering as a result of it.  I think this needs a quick patch in
  indicator-appmenu.
  ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/indicator-appmenu/+bug/1191345/+subscriptions