indicator-application does not send signals when a menu is shown/hidden

Thank you for helping with making Ubuntu better by reporting this bug. I've opened an upstream task and therefore this bug is now Triaged. The status is set to Wishlist because this is a proposal for the addition of a feature that isn't critical to the functioning of the Application Indicators.

For some applications this is a much needed feature. I'm programming a small system monitor to display information like battery status and temperature in a way that uses little space on the screen and I want to use an icon in the notification area for this. Currently I have to stick with a regular Gtk StatusIcon because I would have to poll the hardware information all the time with the Application Indicators which is inacceptable. This should really be fixed in Maverick.

I also need this fixed before I can use appindicator.

One of the apps I am working on needs to be able to update dynamic menus.
Constantly polling network/disk/cpu resources for the 99.99% of the time the menu is not being used not acceptable.

As a me-too: this would be a very useful feature to further simplify the indicator patch for network-manager-gnome (nm-applet); since listening for the show/hide signals from the GtkStatusIcon was how it was initially handled. Having these signals available again would substancially reduce the complexity and increase maintainability for the patch; that's without counting the users for other application developers.

Something I'm developing also requires the signal for when a submenu opens. I can't create the entire submenu structure all in one go on startup, because it could take up lots of memory. Having a signal on submenu opening would allow dynamic population of just that submenu.

On Thu, 2011-02-10 at 08:11 +0000, Michael Judge wrote:
> Something I'm developing also requires the signal for when a submenu
> opens. I can't create the entire submenu structure all in one go on
> startup, because it could take up lots of memory. Having a signal on
> submenu opening would allow dynamic population of just that submenu.

This already works for submenus. The element at the top of the submenu
gets an activate signal when the submenu is opened. Just like with
normal GTK menus.

In what version of appindicator was the 'activate' signal when opening submenus implemented, as it doesn't seem to be triggered when I try it.

I have Ubuntu Lucid 10.04
python-appindicator 0.0.19-0ubuntu4

me-too: I do not see why the status of this bug is "Fix Released", at least in the version of AppIndicator shipped with Oneiric there is still no mechanism in place to get a signal whenb a menu is shown/hidden.

If this has been implemented, please point me to the API documentation for it, so I can start using it.

This is sorely needed. I'm using KDE and when I left-click an icon, I can't get a signal to do anything; only right-clicking works.

I'm also in need of this feature. How else can I clear the status of an indicator (without using a timer)?

There's a way to work around this problem in unity session but the workaround is not nice.

The Unity Panel Service sends a signal called 'EntryActivated' via dbus[1] every time a menu is shown/hidden/changed in the panel. These signals can be used to determine whether our menu is open or not.

Along with the signal, two properties are sent: entry_id and geometry. The entry_id uniquely identifies the menu that has just been made visible. So if the entry_id is the same as the ID of our menu, it's pretty safe to say that our menu is visible and if it's something else, our menu should not be visible. But there's a catch: ASFAIK there's no reliable way to get the entry_id via libappindicator. So we have to resort in another ugly hack and once again rely on Unity Panel Service.

Unity Panel Service DBus interface[1] has a method called Sync that returns details about all items in the panel. Here's one example:
 ('libmessaging.so', '0x7f1d44004d68', 'indicator-messages' ...

So to get the ID for our indicator, we need to find the entry with the name of our indicator and grab the second item from the tuple. Then it's just a matter of implementing the logic to figure out whether the menu is visible or not.

The solution is not optimal and is likely to cause unforeseen problems but it should make the situation a little better than it currently is.

----

As another point, I've been trying to figure out how this could be implemented inside the library. As I know very little about C programming, I can't help much with the implementation itself but have investigated how this could possibly be achieved.

There's this mysterious 'visible' property[2] in the DBusMenuItem. If this property value tells us what the name means, then we should just connect to the 'property-changed' of the root menu item inside 'setup_dbusmenu' and tell the clients that visibility has changed when needed. However the documentation states '...whether the menuitem _should_ be shown or not'. So is the property enough to tell that the menu is actually visible on the screen or is it just telling Unity that 'Could you please show the menu now' and Unity might show it (normal) - or not (something has gone very wrong)...

And when it comes to the StatusIcon fallback, implementing this is nothing more than emitting signal inside 'status_icon_activate' which actually pops the menu when user clicks the icon. Catching the hide event is a bit trickier but it may be possible by catching 'visibility-notify-event' of the menu inherited from gtk_widget (dunno exactly how the fallback is supposed to work but this seems logical :)).

If any of my thoughts are anywhere near being correct, this doesn't seem to be so hard thing to implement. Maybe it's just that when this library isn't used by the default indicators (they all implement their own DBusMenuServers), it doesn't get that much attention from the devs as it should...

----

[1]
 DBus Name: com.canonical.Unity.Panel.Service
 DBus Object Path: /com/canonical/Unity/Panel/Service
 DBus Interface: com.canonical.Unity.Panel.Service
 Introspection XML: http://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/services/panel-main.c

[2] http://...

me-fucking-to: what's up ubuntu? This one too hard for you guys to fix?

Just a friendly bumb. I'd be in need of this as well and nothing has happend for a month.

Sampo555, thank you kindly for taking the time to come up with a work around. It should prove useful.

I still do hold a glimmer of hope that this will one day be fixed.

I have found out how to get the "about-to-show" signal from an application indicator. I'm not sure which version of Ubuntu that this became available in (I'm using trusty), but I think we can call this fixed.

I didn't do this in C originally, so sorry if this sample is not quite right.

AppIndicator *indicator;
GtkMenu *menu;
DbusmenuServer *menuServer;
DbusmenuMenuitem *rootMenuItem;

indicator = app_indicator_new(0, "sample", APP_INDICATOR_CATEGORY_APPLICATION_STATUS);
menu = gtk_menu_new();
// must set menu before getting dbus-menu-server property
app_indicator_set_menu(indicator, menu);
g_object_get(indicator, "dbus-menu-server", &menuServer, NULL);
g_object_get(menuServer, "root-node", &rootMenuItem, NULL);
g_signal_connect(rootMenuItem, "about-to-show", G_CALLBACK(sample_cb), NULL);

According to the Freedesktop StatusNotifierItem specification, each StatusNotifierItem object must provide the following methods:
- ContextMenu
- Activate
- SecondaryActivate
- Scroll

Currently, libappindicator only seem to listen for the `Scroll` method, which it exposes through the `scroll-event` signal, and the `SecondaryActivate`, which it does not expose.

Also, the unity-panel-service does not seem to send a `ContextMenu`, `Activate` or `SecondaryActivate` method call to the StatusNotifierItem registered by libappindicator. It does however send the Scroll method call correctly.

There are a bunch of other ways in which libappindicator and the unity-panel-service do not follow the StatusNotifierItem specifications. It looks like the unity-panel-service and libappindicator are specifically built to fit the needs of Unity, not to comply with the Freedesktop StatusNotifier spec.

To fix this bug properly, firstly the unity-panel-service should send all required method calls to the registered StatusNotifierItem objects. Secondly, libappindicator should listen for these method calls and use this to send signals when the menu is shown/hidden.

Note however that the Ubuntu status menu design guidelines explicitly say not to use application indicators when "You just want the program to take up a small space in the panel when minimized".

IMO, by making application icons behave more "consistently" inside of Unity, they have become inconsistent with other desktop environments, including the ones from OSX and Windows.

I am capable and willing to fix this bug, but I'm afraid doing so allows libappindicator to be used in ways that do not fit the Ubuntu status menu design guidelines. I do not know a lot about the politics in Ubuntu, but this seems to be a touchy subject[3], so my guess is their is no incentive to have it fixed. Could someone set this bug to Won't Fix if this is the case, or tell me where the implementation could be further discussed?

Anyhow, I'll be implementing the workaround described above by dlech for my use-case. It seems to work, but might break when the behavior of unity-panel-service changes (however since this bug is already 6 years old, I don't think this will happen soon).

[1] https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierItem/
[2] https://wiki.ubuntu.com/CustomStatusMenuDesignGuidelines
[3] http://www.markshuttleworth.com/archives/654

I've created PoCs for the workarounds described by ~sjakthol and ~dlech: https://github.com/seppestas/test-libappindicator

I believe this bug is also causing nm-applet to not send scan requests while the networks menu is open. I'm not sure how many people are still using a GNOME desktop with nm-applet rather than gnome-shell, and which is the current default on new installs -- aren't there still environments without gnome-shell selectable from the login screen in the default installation? If so that might still be affecting a large portion of users.

None of the workarounds listed above is easily applicable to nm-applet. At the same time it seems that on Fedora this isn't an issue. Is is possible that Fedora uses libappindicator from a different repository, or carries patches for this? Where even is the "upstream" for libappindicator?