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

[Tanu Kaskinen]

On Tue, 2013-11-26 at 14:06 +0100, David Henningsson wrote:
> 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.

Upstream pulseaudio isn't in the business of showing dialogs. We could
have an example implementation of a daemon that pops up dialogs, if
someone is willing to implement such thing. That would be nice to have,
but I'm not personally bothered much if the only implementation for now
is in indicator-sound. All I care about is that indicator-sound has a
good API to work with, because it means that everyone else then has a
good API available too.

> > 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"?

Well, that depends on how we model the different alternatives. Are they
separate ports on a sink, or is the connected device type an attribute
of a port that represents the jack? I think the latter would be more
logical, but it's probably much easier (and more in line with how we
currently define the port concept) to implement the former, at least if
the alsa mixer needs to be adjusted based on the selection.

But yes, there should be logic in PulseAudio that marks the port or sink
as "type unknown". This could be a boolean flag, or this could be
represented by setting the "selected type" attribute to NULL, if there
will be such an attribute.

I don't know if by "property" you meant specifically a proplist property
or did you mean object properties in more general way. When I said
property, I meant a D-Bus property, but in the libpulse API I'd prefer a
straight struct field. I try to remember use the word "attribute" when
not talking about proplist properties, but sometimes I forget.

> > 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.

Ok, then there's no difference in the amount of necessary daemons,
whichever way the signals/methods calls are sent.

-- 
Tanu