On Tue, 2013-11-26 at 11:39 +0100, David Henningsson wrote: > Hi, > > I talked to Tanu and Arun last week about my what-did-you-plugin-dialog, > and got some push back about my way of popping up the dialog. > > So, instead, what do you think of this solution - does this provide a > good separation between PulseAudio and the GUI process: > > * The dialog will be popped up through DBus activation. We define some > DBus name, e g org.pulseaudio.WhatDidYouPlugIn - and when accessing this > name, the process will be started by DBus. > * There will be DBus methods for popping up and killing the dialog, and > a signal back when the user selects something in the dialog (or cancels it). I'll point out a couple of drawbacks (I don't want to make either of the issues a blocker for upstream inclusion, but please give them a thought). First: A D-Bus based approach has the problem that it doesn't work over the network or other situations where PA is running outside the login session (including the system mode). A native protocol based solution would work everywhere. Second: The usual approach is that the service broadcasts its state via signals and the application controls the service via method calls, and that's how I'd like this thing to work too. PulseAudio shouldn't be in control of dialogs, the UI layer should do that. PulseAudio should just broadcast its state, which could probably be implemented in many ways, one could be to mark each device with an unknown type with a "type unknown" flag, which the UI can then notice and show the dialog. When the user selects something, the UI sets the type property of the device object. If the device object disappears before the user selects anything, the UI closes the dialog (I suppose this is the case that you needed the "close dialog" method for). Relying on signals from PulseAudio implies that there needs to be a daemon listening for those signals. It would be nice to avoid an extra daemon, perhaps the desktop shell is extensible enough to make it possible to listen to those signals in the shell process? I'd expect at least the Gnome shell extensions to be able to do this, I don't know about the Unity shell. How did you intend to support systems that have multiple desktop environments installed, if those DEs implement their own versions of the dialog, and the DE is selected at login time? -- Tanu
