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

[David Henningsson]

2013-11-29 00:39, Tanu Kaskinen skrev:
> 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.

The logic is about
  1) when should the dialog show up
  2) what should it show
  3) what should happen when the user selects something

>
> 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 think it's true that our port concept does not fit exactly to the 
jacks, especially not as you have made ports unidirectional. But I don't 
think the solution to the problem is to introduce *yet* another core 
concept. It's just too much complexity added to the core for one minor 
edge case problem.


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

The logic isn't that complex, unless you try to abstract it into 
something generic. Which is partially of why I prefer the hard coded 
port names at this point.

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

See attached picture. There has been some talk back and forth about a 
"remember my choice" functionality as well, which in turn requires 
somewhere to revert that and being asked again.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sound_source_alert.png
Type: image/png
Size: 22822 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20131129/a8b8c5b1/attachment-0001.png>