david.henningsson at canonical.com
Tue Nov 26 13:31:51 PST 2013
On 11/26/2013 02:47 PM, Tanu Kaskinen wrote:
> 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.
As for the "good API" and related properties. The current logic hard
codes the port names of headphones, headset and headphone mic. I
considered trying to encode the same rules using port properties (like,
when you select headset you also select headphones, but if you select
headphone mic, you need to move away from headphones, and so on).
Trying to abstract all these rules into some port properties turned out
to be much additional complexity for very little gain, so I'm not going
to do that.
That leaves us with the option of implementing the hard coded port logic
inside PulseAudio or outside PulseAudio (i e indicator-sound). I prefer
inside PulseAudio, which also means that PulseAudio controls the dialog,
and this is also what I thought we agreed upon in Edinburgh.
David Henningsson, Canonical Ltd.
More information about the pulseaudio-discuss