[pulseaudio-discuss] What-did-you-plugin-dialog

[David Henningsson]

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