'Twas brillig, and Lennart Poettering at 05/01/10 14:54 did gyre and gimble: >> Yup and the general decision that this approach is "a good thing" and >> something that should be exposed to users. I know Lennart doesn't like >> the idea of this being something users have direct control over, but >> it's something I hear people asking for over and over. Perhaps it's just >> because the automatic approaches don't work, full and there are other >> ways but I quite like the transparency and relative simplicity (i.e. >> users can easily grasp how it works as opposed to black magic hidden >> foo) this approach offers. > > Nah, the automatic scheme I have in mind has not been tested > yet. Right now we store no history of previous settings that could be > used when the newest setting cannot be applied because a device is not > plugged in or suchlike. So what I have in mind is simply have a stack > of choices. Whenever a user makes a choice the stack entry for it is > put on top. If it existed before it is thus removed from the stack > first and moved to the top. If it didnt exist it is created newly. > > That way the user can easily configure the order of devices simply by > moving streams if the order is wrong and that's it. No complex UIs for > that. Ahh right yes. Too many discussions fly about for this tiny brain! Hopefully the actual database in the m-d-m is sufficient for this and all that's really needed is an additional module to manupulate it automatically..... For role based sink moves this wouldn't even conflict with the KDE approach - it's just a simple GUI like pavucontrol (which doesn't support role based sink moves yet) would have the effect of promoting the destination to the top of the list... Cool. -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
