libunity

Unify sound & message menus registration process

Bug #711345 reported by Vsevolod Velichko on 2011-02-01

This bug affects 1 person

	Status	Importance	Assigned to
Messaging Menu	Won't Fix	Wishlist	Unassigned
The Sound Menu	Won't Fix	Low	Unassigned
Unity	Triaged	Wishlist	Unassigned
libunity	Triaged	Medium	Unassigned
unity-2d	Invalid	Undecided	Unassigned
libunity (Ubuntu)	Triaged	Wishlist	Unassigned
unity (Ubuntu)	Confirmed	Undecided	Unassigned

Bug Description

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?

Tags:

Revision history for this message

Mikkel Kamstrup Erlandsen (kamstrup) wrote on 2011-02-02:

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.

Changed in libunity:
importance:	Undecided → Medium
status:	New → Triaged

Revision history for this message

Mikkel Kamstrup Erlandsen (kamstrup) wrote on 2011-02-02:

@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?

Revision history for this message

Vsevolod Velichko (torkvemada) wrote on 2011-02-02:

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) on 2011-02-02

Changed in indicator-sound:
assignee:	nobody → Conor Curran (cjcurran)
importance:	Undecided → Low
status:	New → Triaged

Didier Roche-Tolomelli (didrocks) on 2011-02-21

Changed in unity:
status:	New → Triaged
Changed in libunity (Ubuntu):
status:	New → Triaged

Kalle Valo (kvalo) on 2011-02-22

Changed in indicator-messages:
status:	New → Triaged
importance:	Undecided → Wishlist
Changed in unity:
importance:	Undecided → Wishlist
Changed in libunity (Ubuntu):
importance:	Undecided → Wishlist

Didier Roche-Tolomelli (didrocks) on 2011-05-31

Changed in unity-2d:
status:	New → Triaged

Revision history for this message

Conor Curran (cjcurran) wrote on 2012-03-13:

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.

Changed in indicator-sound:
assignee:	Conor Curran (cjcurran) → nobody

Olli Ries (ories) on 2012-03-13

tags:

added: backlog

Revision history for this message

Lars Karlitski (larsu) wrote on 2012-09-04:

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...

Revision history for this message

Conor Curran (cjcurran) wrote on 2012-09-04:

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 ...

Lars Karlitski (larsu) on 2014-04-11

Changed in indicator-sound:
status:	Triaged → Won't Fix
Changed in indicator-messages:
status:	Triaged → Won't Fix

Marco Trevisan (Treviño) (3v1n0) on 2014-07-25

Changed in unity (Ubuntu):
status:	New → Confirmed

Bryan Quigley (bryanquigley) on 2017-06-29

Changed in unity-2d:
status:	Triaged → Invalid

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

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