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

[Tanu Kaskinen]

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