On Tue, 2013-11-26 at 22:31 +0100, David Henningsson wrote: > 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. Sorry, I didn't understand what you tried to explain in the first two paragraphs. I don't know what logic you're talking about, and what you tried to encode in port properties. I have been thinking about this problem a bit, and it looks to me like our sink, source and port concepts don't fit this use case very well. The user plugs something to a jack, and the user should select the mode for the jack. A sink is not the same thing as a jack, and a port is not the same thing as a jack. I think we should have "jack" as a core concept and expose the jacks to clients, so that clients can set the jack mode when necessary. That's of course a fair bit of work... I don't know if that would solve any of the complex logic that you talked about, but at least it should remove all complexity from the client side. If you're fighting with "how to map the jack mode to ports", I fully agree that the client shouldn't be concerned with that. Out of curiosity, what does the Canonical-designed dialog ask the user? If ALSA says that the jack supports headphones, a headset or a microphone, do you offer a set of radio buttons containing entries for headphones, a headset and a microphone? What if the user plugged in speakers or an external amplifier to the jack, is there a "none of the above" option, and if there is, what does it do? -- Tanu
