On Sat, 2009-01-10 at 00:49 +0100, Michael 'Mickey' Lauer wrote:
> Following up on that, apparantly the way we generate the signal
> registration
> is only working for simple types. The following diff to the vala generated
> code leads at least to the correct signature w/ dbus, so my signal callback
> gets finally called:
>
> void _dynamic_Test1_connect (gpointer obj, const char * signal_name,
> GCallback handler, gpointer data) {
> dbus_g_object_register_marshaller
> (g_cclosure_user_marshal_VOID__BOXED, G_TYPE_NONE, G_TYPE_HASH_TABLE,
> G_TYPE_INVALID);
> - dbus_g_proxy_add_signal (obj, "Test", G_TYPE_HASH_TABLE,
> G_TYPE_INVALID);
> + dbus_g_proxy_add_signal (obj, "Test",
> dbus_g_type_get_map("GHashTable", G_TYPE_STRING, G_TYPE_VALUE),
> G_TYPE_INVALID);
> dbus_g_proxy_connect_signal (obj, signal_name, handler, data, NULL);
>
> So apparantly we need to use dbus_g_type_get_map for a{sv} [and likewise,
> I've
> seen dbus_g_type_get_collection getting used for arrays].
>
> How do we move from here?
This should now be fixed in trunk. The correct dbus-glib specific type
was already used for method calls but not for signal handlers. Can you
confirm that it works for you as well? I'm aiming for a 0.5.5 bug-fix
release soon.
There are some types that are known to not work in signal handlers such
as structs. The plan is to fix this when moving away from dbus-glib, not
feasible in a sane way before.
Jürg
_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
