On Mon, 15.02.10 17:13, Ng Oon-Ee (ngoonee at gmail.com) wrote: > > Wait no longer! > > > > http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/ > > > > Col > > > A nice read Colin, thanks. > > /me also wonders whether all these 'restore' options need to be made > much more transparent. At the very least with a checkbox somewhere > saying "save per-stream routings". I believe in the simplest use cases > (internal laptop speakers or BT headset on the move, USB headset at > home), it would be advantageous to be able to specify that stream > routings should NOT be saved, but that a device preference should > instead be used. > > Of course, this is up to those who write the code (and I believe the > same thing could be achieved by NOT loading module-stream-restore). I > know that it would cover about 90% of my personal use-case though. My own thoughts about all of this are basically: 1) I think it is bad UI to expose the entire history of devices to the user and allow him to rearrange items in there. I am aware that KDE folks disagree with me on this and like stuff like that and Colin is willing to please them. 2) We definitely should save the device history for streams, and when it comes to finding a device for a stream go backwards finding the newest entry that is applicable and apply it. All of this should be automatic and opaque to the user. 3) If that didn't result in anything try to find a good default by some other means, i.e. by used "intended roles" and stuff like that. Should be automatic and opaque to the user as well. 4) The UI would allow the user to fix any setting the system chose and the system will then remember as good as possible. I think this is a simple enough scheme. Certainly, the logic in #3 (especially) might not be obvious to the user, but that doesn't matter: we have to default to something, and it's better to pick the most likely device in an non-obvious way than pick a completely random one. As I understood Colin's blog his suggestion mostly differs in that he wants apps to get full access to the device history and change it, so that what I call the "history" hence becomes more of a "priority list". But uh, while I don't think that would be good idea UI-wise, if that's what makes KDE folks happy this should not be a stumbling block to to merge both approaches. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
