On Mon, 2013-03-18 at 15:44 +0100, David Henningsson wrote:
> On 03/18/2013 03:39 PM, Tanu Kaskinen wrote:
> > On Mon, 2013-03-18 at 14:00 +0100, David Henningsson wrote:
> >> On 02/20/2013 07:23 PM, Tanu Kaskinen wrote:
> >>> @@ -677,13 +676,12 @@ static void handle_get_fallback_sink(DBusConnection *conn, DBusMessage *msg, voi
> >>> pa_assert(msg);
> >>> pa_assert(c);
> >>>
> >>> - if (!c->fallback_sink) {
> >>> - pa_dbus_send_error(conn, msg, PA_DBUS_ERROR_NO_SUCH_PROPERTY,
> >>> - "There are no sinks, and therefore no fallback sink either.");
> >>> + if (!c->core->default_sink) {
> >>> + pa_dbus_send_error(conn, msg, PA_DBUS_ERROR_NO_SUCH_PROPERTY, "No fallback sink set.");
> >>> return;
> >>> }
> >>
> >> Is there a reason for using core->default_sink instead of
> >> pa_namereg_get_default_sink?
> >
> > There's this reason: the property change signals should match what
> > getting the property would return, at least in my opinion. If we'd call
> > pa_namereg_get_default_sink() here, then the signals would indicate that
> > no fallback has been set, but getting the fallback would indicate that
> > there's some fallback set.
> >
> > It would definitely be good to have a comment about this here.
>
> What about caching the result of pa_namereg_get_default_sink in the
> beginning, and only send out a dbus signal if the result of the function
> has actually changed?
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?
--
Tanu
