[pulseaudio-discuss] Notification and feedback system

[Colin Guthrie]

Lennart Poettering wrote:
> On Wed, 30.07.08 22:51, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> 
>> Lennart Poettering wrote:
>>> padevchooser is not unfixable. It's just that someone should sit down
>>> and get rid of the braindamage that is in there. Patches welcome.
>> I've been wanting to write a pa subsystem for a while that could ask the 
>> user some questions and await feedback, but I'm not really 100% sure if 
>> it's sensible or not.
> 
> If you want to synchronously ask questions on certain events this
> might be problematic. (because applications don't expect this. They
> assume that creating a playback stream is takes no time. However, if
> you pop up a dialog in that case this will cause the client creating
> the stream is frozen. 
> 
> OTOH if things happen asynchronously everything should be
> fine. (i.e. let the connection go through, ask the user, and then
> changeit while it is already existing)

I was thinking of a callback system, much like libnotify (not looked at 
it for a while but I think that was how it's based).

>> I was thinking of something pretty simple that would be capable of:
>>    1. Simple notification popups for information (detected new network 
>> device, new USB device etc.)
>>    2. Simple yes/no questions. (New Sink found, do you want to move all 
>> active streams to it and set it as default?)
> 
> /me is not a fan of unnecesary questions...

So don't load the module :D

But I know what you mean. There are legitimate reasons to ask sometimes 
tho'. I think the example given above is one that users would genuinely 
use....

>>    3. Ask simple questions (Your apple airport device requires a 
>> username and password, please enter it now.)
> 
> That makes a lot of sense. Though I am not sure how the internal
> control flow for this would look like.

I think it can be made to work, especially if there is an internal 
(async) state machine and a callback when done entering the info....


>> I would envisage that the core would be extended to provide a few 
>> functions that modules could call to do the necessary and then I'd 
>> expect a module could be written to register as a "notification 
>> handler". That would allow for a module that interfaces with e.g. 
>> libnotify to be written (this would allow for a different KDE module to 
>> be written too).
>>
>>
>> For 1 and 2, it would be pretty simple Nut for 3 it could be a bit more 
>> complex.
>>
>> Lennart, have you got any thoughts on this? Am I way off track here or 
>> is this vaguely sensible?
> 
> Yes, padevchooser already did the notification stuff, however did it
> from the wrong source. I think haveing a client side agent like this
> makes a lot of sense.

Cool. I'll try and work on the basics at somepoint and see where it goes.

Col