[Bug 26249] add GObject-Introspection bindings

[bugzilla-daemon at freedesktop.org]

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

--- Comment #19 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-04-22 08:25:30 PDT ---
Merge blockers
==============

In "Initial work on generating gobject-introspection":

> +       LD_LIBRARY_PATH=.libs$${LD_LIBRARY_PATH:+:$$LD_LIBRARY_PATH} \

If you invoke it using $(top_builddir)/libtool --mode=execute
$(INTROSPECTION_COMPILER) ... (like we do for valgrind in the regression
tests), you shouldn't need to set LD_LIBRARY_PATH by hand.

>   * tp_asv_set_boolean:

I think it's dangerous to bind these setters into other languages - they make
assumptions about the memory allocation model of the GHashTable that are not,
in general, true. (Also, we don't bind tp_asv_new, which is the only documented
way to create a suitable hash table :-)

> -               --pkg dbus-glib-1 \

Do we want to keep the dbus-glib-1 pkg-config package, even though we've
dropped the GObject-Introspection-level dependency? I think that would avoid
needing @DBUS_CFLAGS@?

> JS example that retrieves the statuses of valid accounts
> Connection Manager example
> Contact list example that makes a low-level D-Bus call

I don't think we should ship these at all, for now.

In future, examples that are exemplary should go in examples/client/ (or
perhaps in examples/client/js/), and non-automated tests should go in
tests/manual/ or something, to make it very obvious that unlike the rest of the
tests, they are not run automatically.

Not merge blockers
==================

In "Initial work on generating gobject-introspection":

> +       proxy.c _gen/proxy-introspectable.h \
> +       account.c account.h \
> +       account-manager.c account-manager.h \
> +       connection.c connection.h \
> +       connection-handles.c \
> +       connection-manager.c connection-manager.h \
> +       channel.c channel.h \
> +       handle.c handle.h \
> +       dbus-daemon.c dbus-daemon.h \
> +       interfaces.c interfaces.h \
> +       intset.c intset.h \
> +       dbus.c dbus.h \
> +       capabilities.c capabilities.h \
> +       contact.c contact.h \
> +       defs.h \
> +       debug.c debug.h \
> +       _gen/telepathy-enums.h \
> +       _gen/telepathy-interfaces.h

I'd still like a brief status report for each of those files: unchecked /
completely OK / only foo and bar checked / whatever.

It might help to look at the generated .gir and see if it looks sane.

>     * TpChannel::group-members-changed:

Why is this already re-annotated in the initial commit? Also, weren't you going
to (skip) it?

>    * TpChannel::group-members-changed-detailed:

Likewise, but without the (skip)ping.

> @@ -738,8 +738,8 @@ connection_got_contact_attributes (TpConnection *self,
>   * @user_data: arbitrary user-supplied data

Why is this already re-annotated in the initial commit? Also, user_data could
probably be annotated as (closure).

> Annotate TpProxy

Have you checked all of TpProxy's API? If not, "Annotate
tp_proxy_prepare_async" would seem a more appropriate commit message.

> Annotate TpChannel
>  342  * tp_channel_borrow_connection:

Shouldn't methods that duplicate a property be (skip)ped? I consider this
method to be a "C binding" :-)

> + * Returns: (transfer none): a borrowed reference to the #TpContact:connection

I think this is a "C binding" and so should be (skip)ped? In fact, most of the
TpContact stuff falls into that category.

> + * @contacts: (array length=n_contacts): An array of @n_contacts TpContact
> + *  objects (this callback is
>   *  not given a reference to any of these objects, and must call
>   *  g_object_ref() on any that it will keep), or %NULL on unrecoverable errors

Shouldn't this have an explicit (transfer none)? Likewise for requested_ids,
failed_id_errors?

> + * tp_get_bus_proxy: (skip)

All other deprecated functions should probably be (skip)ped, too.

I'd quite like to see a straight Javascript port of the existing client
examples (inspect-connection and friends) in examples/.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.