[Bug 77189] [next] make TpBaseConnection GVariant-based

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77189

--- Comment #10 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
>  * To support user-defined contact groups too, additionally implement
>  * %TP_TYPE_CONTACT_GROUP_LIST in the #TpBaseContactList subclass, add the
>  * %TP_IFACE_CONNECTION_INTERFACE_CONTACT_GROUPS1 interface to the output of
>- * #TpBaseConnectionClass.get interfaces_always_present, and implement the
>- * %TP_TYPE_SVC_CONNECTION_INTERFACE_CONTACT_GROUPS1 in the #TpBaseConnection
>- * subclass using tp_base_contact_list_mixin_groups_iface_init().
>+ * #TpBaseConnectionClass.get interfaces_always_present.

That function no longer exists. I think you can just end the sentence after
"subclass"?

> +           _tp_gdbus_connection_interface_contact_groups1_emit_groups_changed (
> +                self->priv->contact_groups_skeleton,
> +                g_variant_new_fixed_array (G_VARIANT_TYPE_UINT32,
> +                    members_arr->data, members_arr->len, sizeof (TpHandle)),

A static assertion is desirable here (again); or we could add
tp_handle_set_to_variant().

> -          g_hash_table_insert (map, GUINT_TO_POINTER (handle),
> -              (gchar *) tp_handle_inspect (self->repo, handle));
> +          /* We don't bother dupping the strings: they remain valid as long as
> +           * the connection's alive and hence the repo exists. */
> +          g_variant_builder_add (&builder, "{u&s}", handle,
> +              tp_handle_inspect (self->repo, handle));

I would be suspicious of that reasoning (although it matches current behaviour,
which might well have been written by my younger and less defensive self), but
it isn't actually true, because C-to-GVariant always copies strings anyway and
the & is meaningless.

+  gchar *object_path;
...
+  g_object_get (chan,
+      "object-path", &object_path,
+      "channel-properties", &properties,
+      NULL);
...
+  g_variant_builder_add (builder, "(&o at a{sv})", object_path, properties);
+  g_variant_unref (properties);

The "&" doesn't do anything, and the object path is leaked.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.