[pulseaudio-discuss] Notification and feedback system
gmane at colin.guthr.ie
Wed Jul 30 16:16:54 PDT 2008
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
>> 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
>> 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.
More information about the pulseaudio-discuss