dx-packages team mailing list archive

[Seppe Stas <seppestas@xxxxxxxxx>]

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

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

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

Status in GRandRock:
  New
Status in libappindicator:
  Confirmed
Status in Screenlets:
  Fix Released
Status in libappindicator package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: indicator-application

  For the xrandr plugin in gnome-settings-daemon we would need signals
  when the menu is shown/hidden, so that we can display the display
  labels when the menu is shown.

To manage notifications about this bug go to:
https://bugs.launchpad.net/grandrock/+bug/522152/+subscriptions