On Mon, 2013-03-18 at 16:21 +0100, David Henningsson wrote: > On 03/18/2013 04:15 PM, Tanu Kaskinen wrote: > > I guess you mean this: the D-Bus code has its own default sink variable, > > let's call it dbus.default_sink here. dbus.default_sink is always the > > same as core.default_sink when core.default_sink is non-NULL. > > > > When core.default_sink changes to NULL, the D-Bus code calls > > pa_namereg_get_default_sink() and saves the result to dbus.default_sink. > > If that causes a change to dbus.default_sink, a signal is sent. > > > > When someone queries the property value and core.default_sink is NULL, > > pa_namereg_get_default_sink() is called again, the result is stored in > > dbus.default_sink and the if that causes a change to dbus.default_sink, > > a signal is sent. Then the result is sent as the reply to the original > > query. > > > > This would indeed achieve the desired consistency between the signals > > and the property query results. I'll implement this, unless this > > question causes you to change your mind: > > > > Does it really make sense to return a fallback sink when queried, if > > there's no signal sent when the "ad-hoc default" changes? This applies > > to the native protocol as well. Let's use pavucontrol as an example. It > > shows the current default sink. If core.default_sink is NULL, the > > default that pavucontrol shows is the highest-priority sink at the time > > of the initial pa_context_get_server_info() call. If a higher-priority > > sink appears, pavucontrol won't get a signal about the change in the > > "ad-hoc default" sink, so it will end up displaying incorrect > > information. Would it be better to not show any sink as being the > > default, when the default hasn't been explicitly set? > > Ok, fair point. It sound like you need to update (and possibly signal) > dbus.default_sink when sinks are added and removed too, then? Are there > other events that can cause the result of pa_namereg_get_default_sink to > change, so that pa_namereg_get_default_sink() and dbus.default_sink get > out of sync? Assuming that sink priorities can't change at runtime, then the default sink can change only when sinks are added or removed (based on the current pa_namereg_get_default_sink() implementation). As I said, this problem is not really D-Bus specific, so the solution shouldn't be D-Bus specific either. I propose that we add a new variable: pa_core.configured_default_sink, which behaves as pa_core.default_sink behaves currently, and we change pa_core.default_sink so that the namereg updates it whenever sinks are added or removed if pa_core.configured_default_sink is NULL (if it's non-NULL, pa_core.default_sink is the same as pa_core.configured_default_sink). -- Tanu
