Currently, to pull values out of an a{sv} in C we can use tp_asv_get_string and friends, but to populate one we need to say tp_g_value_slice_new (type); g_value_set_...; g_hash_table_insert (asv, key, value); which is kind of verbose. I suspect we should also have tp_asv_new () which creates a GHashTable with appropriate key and value destructors. tp_asv_set_handle (cf. tp_message_set_handle) would be nice, but would involve using a type other than GHashTable (or some incredible GValue trickery behind the curtains) for a{sv}s which might end in tears.
I think this is fixed in a different way by my 'sliced-woot' branch, which I just merged. This adds functions like tp_g_value_slice_new_uint, allowing for this syntax (code copied from one of the tests): GHashTable *details = g_hash_table_new_full (g_str_hash, g_str_equal, NULL, (GDestroyNotify) tp_g_value_slice_free); ... g_hash_table_insert (details, "actor", tp_g_value_slice_new_uint (camel2)); ... g_hash_table_insert (details, "change-reason", tp_g_value_slice_new_uint (TP_CHANNEL_GROUP_CHANGE_REASON_KICKED)); This avoids the problem that tp_asv_set_foo needs to know how the memory for the GValue is meant to be allocated (g_slice_new vs. g_malloc), by making it explicit. wjt agrees that this is sufficient, so I'm closing this bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.