Menus updated at runtime aren't rendered correctly

Bug #524150 reported by Travis B. Hartwell
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Application Indicators
Fix Released
High
Jan Arne Petersen

Bug Description

(This information is a copy of a recent mail I sent)

I still am having problems with Gnome Bluetooth. I would guess the
problem is somehow in an interaction with app indicators, since the
menus are created just fine in the GtkStatusIcon version.

A picture is probably the best description of what is wrong, so I'll
attach screenshots showing the correct rendering (from
bluetooth-applet using a GtkStatusIcon) and the rendering that app
indicators currently use.

In parts of the code, it hides various menu entries for the
devices as they are discovered not to have certain capabilities, but
for some reason this isn't being reflected in the indicator applet.

Ted suggested I see what dbusmenu-dumper is showing, so I ran the
following command:

usr/lib/libdbusmenu/dbusmenu-dumper
--dbus-name=org.gnome.Bluetooth.applet
--dbus-object=/org/ayatana/NotificationItem/bluetooth_manager/Menu

I'll attach the output of this command. From the output, I can see
the menu is certainly displaying what it got, so there is something
going on before it is transferred across dbus.

I'll attach my current patch for Gnome Bluetooth, which is against
version 2.29.91, which is what is currently in Lucid. The executable
to test is applet/bluetooth-applet. The code that is important to
look at:

applet/notify.c
applet/main.c

All of the menu related stuff is in main.c.

Let me know if there is anything I can do to help out or give you
further information.

I'll attach additional information (screenshots, patches, and
debugging output) after creating the bug.

Revision history for this message
Travis B. Hartwell (nafai) wrote :
Revision history for this message
Travis B. Hartwell (nafai) wrote :
Revision history for this message
Travis B. Hartwell (nafai) wrote :
Revision history for this message
Travis B. Hartwell (nafai) wrote :
Changed in indicator-application:
assignee: nobody → Cody Russell (bratsche)
description: updated
Jorge Castro (jorge)
Changed in indicator-application:
importance: Undecided → High
Revision history for this message
David Barth (dbarth) wrote :

Cody, can you help unblock Travis on this one? Thanks

Changed in indicator-application:
status: New → Triaged
Cody Russell (bratsche)
Changed in indicator-application:
status: Triaged → In Progress
Revision history for this message
Jan Arne Petersen (jpetersen) wrote :
Changed in indicator-application:
assignee: Cody Russell (bratsche) → Jan Arne Petersen (jpetersen)
Revision history for this message
Cody Russell (bratsche) wrote :

Yeah, looks fine although I don't have time to test it. Presumably the same thing should happen with the "add" and "remove" callbacks that are set in app_indicator_set_menu()? Right now it's just rebuilding the whole menu, which was a quick hack thrown in there.

Revision history for this message
Jan Arne Petersen (jpetersen) wrote :

Additionally fixes setting the visibility property correctly.

Revision history for this message
Jan Arne Petersen (jpetersen) wrote :

Seems to be fixed now.

Changed in indicator-application:
status: In Progress → Fix Committed
Changed in indicator-application:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.