It is trivial to do this in Ubuntu 10.04. The question is specific to Ubuntu 12.04.
A composition using the dbus with implementation details in followup is missing for some reason so an alter ego composed the answer (the trivial but somewhat laborious process is explained here).
This response regarding
gdbus is useful but this answer is super useful – (quiescent system overhead has now been reduced to an acceptable ~10%).
some pertinent references
(src: answer to What is the difference between indicators and a system tray?:
Here is the documentation for indicators:
Application indicators | Ubuntu App Developer
libindicate Reference Manual
libappindicator Reference Manual
ref: How can the application that makes an indicator icon be identified? (This link inappropriately redirects to https://askubuntu.com/questions/184589/how-can-menu-bars-that-require-a-right-click-be-activated-like-ubuntu-versions)
bookmark: How does one find out which application is associated with an indicator icon in Ubuntu 12.04?
is a serious question for reasons & problems outlined below and for which a significant investment has been made and is necessary for remedial purposes.
reviewing refs. to find an orchestrated resolution …
(an indicator ap. indicator maybe needed)
This has nothing to do (does it?) with right click.
How can an indicator's icon in Ubuntu 12.04 be matched with the program responsible for it's manifestation on the top panel?
A list of running applications can include all processes using
How is the correct matching process found for an indicator?
How are the sub-indicator applications identified? These are the aps associated with the components of an indicators drop-down menu. (This was to be a separate question and quite naturally follows up the progression. It is included here as it is obvious there is no provisioning to track down offending either sub or indicator aps. easily.)
(The examination of SM points out a rather poignant factor in the faster battery depletion and shortened run time – the ambient quiescent CPU rate in 12.04 is now well over 20% when previously, in 10.04, it was well under 10%, between 5% and 7%! – the huge inordinate cpu overhead originates from Xorg and compiz – after booting the system, only SM is run and All Processes are selected, sorting on %CPU – switching between Resources and Processes profiles the execution overhead problem – running another ap like gedit "Text Editor" briefly gives it CPU priority – going back to S&M several aps. are at the top of the list in order: gnome-system-monitor as expected, then: Xorg, compiz, unity-panel-service, hud-service, with dbus-daemon and kworker/x:y's mixed in with some expected daemons and background tasks like nm-applet – not only do Xorg and compiz require excessive CPU time but their entourage has to come along too! further exacerbating the problem – our compute bound tasks no longer work effectively in the field – reduced battery life, reduced CPU time for custom ap.s etc. – and all this precipitated from an examination of what is going on with the battery ap. indicator – this was and is not a flippant, rhetorical or idle musing but has consequences for the credible deployment of 12.04 to reduce the negative impact of its overhead in a production environment)
(I have a problem with the battery indicator – it sometimes has % and other times hh:mm – it is necessary to know the ap. & v. to get more info on controlling same. ditto: There are issues with other indicator aps.: NM vs. iwlist/iwconfig conflict, BT ap. vs RF switch, Battery ap. w/ no suspend/sleep for poor battery runtime, … the list goes on)
How can I find Application Indicator ID's?
suggests looking at:
[Ordering Index Overrides] nm-applet=1 gnome-power-manager=2 ibus=3 gst-keyboard-xkb=4 gsd-keyboard-xkb=5
which solves the battery ap. identification, and presumably nm is NetworkManager for the rf icon, but the envelope, blue tooth and speaker indicator aps. are still a mystery.
(Also, the ordering is not correlated.)
Mind you, it was simple in the past to simply right click to get the
About option to find the ap. & v. info.
browsing around and about:
perhaps?/presumably? the information sought may be buried in
A reference in the comments was given to:
What is the difference between indicators and a system tray?
quoting from that source …
Unfortunately desktop indicators are not well documented yet: I couldn't find any specification doc …
Well … the actual document
does not help much but it's existential information provides considerable insight …
The Application Indicator Service has an internal API that will allow grabbing a list of all the indicators, which includes their DBus addresses. You can do that using this command line:
You'll get back something not super useful, as it's in a psuedo-JSON format. If you write a script you can pull it into a parser and work with it. If you're curious about doing it just once, just read through the text. You're looking for a field that is like this:
:1.XXXThat is the DBus address for the indicator.
Once you have the address for the indicator you can ask DBus what the PID is for that indicator. You request the PID of
After you now have the PID you can ask
/procfor information on the process. For example if you wanted to know the command use to launch process number
1you could do: