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. https://launchpad.net/~diwic
