On Sun, 04 Jan 2009 17:06:10 +0000, Colin Guthrie wrote: > Thanks for the feedback :) > > I'm not totally convinced that what you suggest is actually a simpler > approach tho'! > > Without giving it too much thought, to do it this way would require > changes to the protocol to allow the client application (pavucontrol) to > move the stream only for the current session verses always. It would > require changes to module-device-restore to not write it's database for > certain moves, and it would require changes to something (not sure what) > to ask users if they want to move all stream over which would have to > read and write the database maintained by module-device-restore. This > would also make the notification system an integral part of pulse UI, > which I'm not totally convinced about (while I would certainly use it, > there are some circumstances where it is not possible (or rather not > convenient e.g. when interacting with a remote PA instance not attached > to the local display). > > With the approach I suggested it would only require a single new module > to be written (assuming it's actually possible to change the sink it's > piggy backing on to underneath without causing major complications). > > Col Uh, sorry, I meant simpler/more naturally approach just from a users/ui point of view (imho), I certainly can't oversee the impacts of extending existing modules versus writing a new one. :) (I could imagine having another sink could be quite confusing to new users, whereas users already knowing what sinks are having less problems of understanding what 'default' in pulseaudio means and how to deal with it.) Jens
