[patch] generate marshallers and metadata from dbus-glib-tool
Havoc Pennington
hp at redhat.com
Thu Feb 10 11:52:35 PST 2005
Hi,
Can you send an example of the generated code? Sort of hard to visualize
from the g_print() ;-)
On Thu, 2005-02-10 at 00:21 -0500, Colin Walters wrote:
> Index: dbus/dbus-glib.h
> ===================================================================
> RCS file: /cvs/dbus/dbus/dbus/dbus-glib.h,v
> retrieving revision 1.7
> diff -u -d -r1.7 dbus-glib.h
> --- dbus/dbus-glib.h 31 Jan 2005 02:55:12 -0000 1.7
> +++ dbus/dbus-glib.h 10 Feb 2005 05:17:54 -0000
> @@ -89,9 +89,14 @@
> typedef struct DBusGObjectInfo DBusGObjectInfo;
> typedef struct DBusGMethodInfo DBusGMethodInfo;
>
> -typedef DBusHandlerResult (* DBusGMethodMarshaller) (DBusGConnection
> *connection,
> - DBusGMessage
> *message,
> - void
> *user_data);
> +/* These two are needed just for DBusGMethodMarshaller */
> +struct DBusConnection;
> +struct DBusMessage;
> +
> +typedef DBusHandlerResult (* DBusGMethodMarshaller) (struct
> DBusConnection *connection,
> + struct
> DBusMessage *message,
> + GCallback
> function,
> + void
> *user_data);
>
I don't understand this change; what was wrong with
DBusGConnection/DBusGMessage ? The idea is to fully wrap dbus.h
> /**
> * Object typically generated by dbus-glib-tool that
We need to find all these dbus-glib-tool references and change them to
whatever I renamed it to...
> +interface_info_new (const char *name, const char *c_name)
I'd suggest some more extensible approach. Remember we may use this for
other languages besides C.
We might think first about the introspect format; can we change the
introspect format to have something like:
<method name="Whatever">
<binding name="C" function="foo_bar_Whatever"/>
<binding name="Python" method="Whatever"/>
</method>
Where <binding> subelements and attributes are defined per-binding, and
all of the node types can have <binding> data.
> +static char *
> +get_marshaller_name (GSList *args)
Suggest merging this function with the get_marshaller used for signals
in dbus-gproxy.c; via some clever macros, we could probably list the
marshaller name once and map it to both the function pointer and the
string form of the marshaller. Not sure of the details. However, we want
to be sure the same mapping from dbus signature to marshaller is always
used.
I guess it's more complicated than that. We want one function to
retrieve standard marshallers. If a standard marshaller isn't retrieved,
we can generate a marshaller on the fly and that code will be specific
to the "server side" (won't be done for proxies)
> connection = dbus_g_bus_get (DBUS_BUS_STARTER,
> &error);
> - if (connection == NULL)
> + if (error != NULL)
If this change is needed, there's a bug somewhere - the two tests should
always be TRUE/FALSE at the same time.
Havoc
More information about the dbus
mailing list