'Twas brillig, and Lennart Poettering at 17/02/10 02:13 did gyre and gimble: > 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. While I'm not totally signed up to the fact that it's a good idea, it's also very little effort to support it. This history will continue to remain a non-core concept so it shouldn't really get in the way. > 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. Good. > 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. So intended roles should slot in here? After we've tried to find the right device for the stream via specific history list? My immediate thought on this is that m-i-r should be quite forceful here, but I'm willing to concede the point as I'm not totally convinced with myself. The reason I say that is that m-i-r is pretty neat with VoIP stuff and I'd really like it to work, but if e.g. someone uses VoIP-App+Webcam there is a good chance that they will have manually moved the VoIP-App input stream to the Webcam Mic. This means that when they then open a BT headset, only the output stream is moved across, and the input stream is still stuck on the input. That's maybe fair enough. The alternative of course is that m-i-r does not actually do any internal stream moves itself, it just becomes a way to automatically inject devices into the role-based priority list (aka history) at the appropriate place. I've not looked at the code recently but IIRC m-i-r relies on having a specific device that is most appropriate for a given role. If so, then this approach could work nicely and make the "order of rule application" logic a bit simpler perhaps (due to it all being in m-s-r)? I'd suggest the m-i-r logic should be "I've found an appropriate device for role X. Is device in prio-list for role X? Yes: Noop, No, Add it in at the top". The major downside is that m-i-r would then not work without m-s-r and I'm not sure that's a great idea for embedded/phone people who may or may not actually want m-s-r? (I think they probably do want m-s-r, but not 100% sure as I don't tend to think from this perspective very often) and I could probably relatively easily code m-i-r to detect if m-s-r is in use and take appropriate action depending on that. But overall I think you're right on this one. > 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. Well if the m-i-r worked via manipulating the role-based priority list rather than actually moving streams itself then the UIs would reflect this. In terms of pavucontrol for example, it would show the device being used for the role widget (I'd obviously have to add the device drop down to the rolewidget just like with streamwidget) and for KDE folks they'd see the priority list automatically change the first time the device became available, but be able to change it if they like. It just becomes a way of picking a sensible default once, which I believe is the ultimate goal. > 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". Indeed. You've not specifically mentioned the fact that I'm really proposing three priority/history lists (per-app, per-role, default) that should be checked in order so I'm not sure how signed up you are to that idea overall, but the general principles at play here are certainly not much different. > 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. Indeed, that's ultimately what I've tried to cater for: making the system work nicely for both simple UIs (which will be useful on e.g. phones/embedded systems) and more exposed/user controlled UIs for those that want it (both Gnome and KDE would, in my book, be considered "more exposed" than the simplest possible interface, but with KDE being "more exposed" than the Gnome one is likely to ever be) Col -- 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/]
