dx-packages team mailing list archive

[Lars Uebernickel <lars.uebernickel@xxxxxxxxxxxxx>]

** Changed in: indicator-sound
       Status: Triaged => Won't Fix

** Changed in: indicator-messages
       Status: Triaged => Won't Fix

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

Title:
  Unify sound & message menus registration process

Status in The Messaging Menu:
  Won't Fix
Status in Sound Menu:
  Won't Fix
Status in LibUnity:
  Triaged
Status in Unity:
  Triaged
Status in Unity 2D:
  Triaged
Status in “libunity” package in Ubuntu:
  Triaged

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?

To manage notifications about this bug go to:
https://bugs.launchpad.net/indicator-messages/+bug/711345/+subscriptions