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
