Unify sound & message menus registration process

[Vsevolod Velichko]

I would like to propose the unification of the application registration process.
AFAIK, at the moment there is a following situation with the registration process:
1. Sound Menu. Every application registers itself after the first start (providing desktop-file location through the dbus). The only preregistered application is banshee.
2. Messages menu. Every application registers itself, placing file with desktop-file location into the /usr/share/indicators/messages/applications/ folder (or user folder). Default launcher list (evolution, empathy and gwibber) is hardcoded, rather than stored in gconf scheme, as indicator-sound does.

In fact, I see no united way to deal with all that stuff. I suppose, that indicator interaction API should be similar in most cases, however in this case they are absolutely different.
First, messages-applications have no dbus-method to register themselves. Yep, that's not fatal, it only makes maintainers should care about indicator creation.
And second, sound-applications are unable to preregister themselves during the installation. Yep, this is conflicts with SoundMenu spec, but really why it's stated in spec? And why it's different from Messages policy? The main problem are applications who don't provide any GUI and are not intended to be started as usual applications, but as something like user-session daemons. In fact I can name only one such application :) — my mpd-sound-menu, in most cases user wants it to be started with his session to display MPD status.

Your suggestions?

[Mikkel Kamstrup Erlandsen (kamstrup)]

Hi Vsevolad, thanks for noticing this. We are whipping up a new library, lp:libunity, which is intended to give app developers a one stop shopping solution to integrate with all pieces of the Unity shell,. including the messaging- and sound indicators. A central goal off that task is to come up with a common set of API patterns for the registration.

I'll try and use this bug as hub for collecting the process on that.

[Mikkel Kamstrup Erlandsen (kamstrup)]

@Vsevolad: It just struck me that the solution to your particular problem is probably to install an autorun file for mpd-sound-menu which will make it run on session launch, giving you the hook to register with the soundmenu you need?

[Vsevolod Velichko (torkvemada)]

Hi Mikkel, you mean the installation of autorun into /etc/xdg/autorun/ ? You're right, that'll solve my particular problem.

Is there any documentation for libunity? I've checkouted the branch, there is nothing but vala sources there :(

[Conor Curran (cjcurran)]

I would consider (of course) the i-sound modus operandi to be superior to that of the messaging indicator (sorry Ted).
Of course I'm open to suggestions. I don't really know who should take this bug on.

[Lars Karlitski (larsu)]

The messaging menu gained a new way for applications to register, based on a simple dbus call. The list of applications that are shown is now stored in a gsettings key.

Isn't the sound menu registration based on MPRIS? It wouldn't make much sense to use MPRIS for the messaging menu...

[Conor Curran (cjcurran)]

Indeed it would not Lars. Apps register with the sound menu by the sound service monitoring DBus. Any app that brings up the DBus name in the form of org.mpris.$APP_NAME will grab the attention of the service and if compliant will appear in the menu. At this point the app is remembered via GSettings and from that moment on will appear in the menu even if the app is not running.
To remove the app the user needs to remove it from the i-sounds GSettings ...