pe, 2010-02-05 kello 10:11 +0000, Colin Guthrie kirjoitti:
> I also generate a sink input|source output change subscription message
> here. This is arguably not "correct" as the sink input itself is not
> changing, although the rules governing it's routing have. In lieu of a
> proper subscription system for "routing rules" I just fire this one.
You seem to fire the event unconditionally after
si->save_sink = FALSE;
and
so->save_source = FALSE;
Is it guaranteed that the previous value is always TRUE? If not, I think
you should write
save_changed = si->save_sink;
si->save_sink = FALSE;
if (save_changed)
pa_subscription_post(...);
If a TRUE value is guaranteed, then a comment about it would be
appropriate.
> Overall I think this approach gives us everything we currently have, but
> exposes a bit more clarity to users as to WTF is going on. Having the
> stream arbitrarily using a role based rule and having several
> applications streams suddenly jump to new devices when you change one
> applications device is NOT intuitive to the users. Having this fallback
> scheme is much more user friendly and exposing the fact that device
> selection is "Automatic" is something that IMO we must do.
Can you give an example of a case where individual app control (as
opposed to role control) is needed? Above you argue that it's
non-obvious to the user that by moving Rhythmbox, Amarok moves too. I
agree. But I think the problem is that the UI emphasizes the application
instead of the role. Maybe it would be best to display all roles all the
time, like the Event role is now displayed always. The UI could, in
addition, show the individual streams under the roles, if any are
currently active.
--
Tanu Kaskinen
