On 11/26/2013 01:54 PM, Tanu Kaskinen wrote: > 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. Ok, fair point. > 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. Well, I could implement all the logic outside PulseAudio, which would be the result if we did it that way. But I believe that's the exact opposite of what we wanted, because then I would do all the coding in indicator-sound, and upstream PulseAudio would not have any dialog. > PulseAudio should just > broadcast its state, which could probably be implemented in many ways, > one could be to mark each device So, on jack plug in, there should be some logic in PulseAudio that sets a property on the sink and the source with the value "port type unknown"? > 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? They would just grab the DBus name directly on login. If the name is present I believe DBus will not activate a new process. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
