[Bug 27792] add Vala bindings

[bugzilla-daemon at freedesktop.org]

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

Travis Reitter <travis.reitter at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://git.collabora.co.uk/ |http://git.collabora.co.uk/
                   |?p=user/treitter/telepathy- |?p=user/treitter/telepathy-
                   |glib.git;a=shortlog;h=refs/ |glib.git;a=shortlog;h=refs/
                   |heads/vala-bindings-gi-reba |heads/vala-bindings-gi-prep
                   |se2                         |

--- Comment #12 from Travis Reitter <travis.reitter at collabora.co.uk> 2010-06-17 11:06:02 PDT ---
(In reply to comment #10)

The new branch should address all the problems below - please do a final check
on it.

> Can't we (skip) this function and let bindings use the property? This function
> is basically a "C binding" for the property anyway.

Yup, (skip)ped.

> If this patch was correct, I'd be happy to merge it immediately, even if the
> Vala bindings still need fixes - it's not blocked.
> 
> > +/* XXX: the Return value line is > 80 chars because of bgo #618569 */
> 
> Does bgo#618569 actually break our bindings, or just make their documentation
> wrong? If it's the latter, we don't need to go to great lengths to avoid it -
> just get it fixed upstream (which has indeed been done) and the documentation
> will become correct eventually. I'm happy to bump the required g-i version.

It kind of mangled our docs (relocated the second line to the doc text for the
next element, I believe), but since it's fixed in the version we require, I've
snipped this.

> http://git.collabora.co.uk/?p=user/treitter/telepathy-glib.git;a=commitdiff;h=dca6893a95
> > - ... (element-type Tp.ChannelRequest)...
> > + ... (element-type TelepathyGLib.ChannelRequest)...
> 
> Looks good, and is not blocked. Please do a git grep and fix any other
> occurrences too.

I looked for any other instances of "type Tp" (which also gets the "type"
keyword), and it only matched the TpConnectionStatus[Reason], which was
resolved below.

> > +  PKG_CHECK_MODULES(LIBTEST_VALA_LOWLEVEL,
> > +                    [glib-2.0 >= 2.22,
> > +                     gobject-2.0 >= 2.22,
> > +                     telepathy-glib])

I know I fixed at least one other instance of this - must have missed this one.

> > +VAPIGEN = $(shell pkg-config vala-1.0 --variable="vapigen")
> 
> This should come from configure.ac - ask pkg-config, and AC_SUBST it.

Good idea

> > +++ b/vala/telepathy-vala.pc.in
> 
> There should be an accompanying telepathy-vala-uninstalled.pc.in.

Fixed

> http://git.collabora.co.uk/?p=user/treitter/telepathy-glib.git;a=commitdiff;h=4dc1c9bbbb84c790a
> > Add a few more g-i annotations for (uint -> TpHandle) and (uint -> TpConnectionStatus
> 
> This is two patches, as the commit message indicates :-P
> 
> > -   * @old_status: old #TpAccount:connection-status
> > -   * @new_status: new #TpAccount:connection-status
> > -   * @reason: the #TpAccount:connection-status-reason
> > +   * @old_status: (type TpConnectionStatus): old #TpAccount:connection-status
> > +   * @new_status: (type TpConnectionStatus): new #TpAccount:connection-status
> > +   * @reason: (type TpConnectionStatusReason): the
> > +   *  #TpAccount:connection-status-reason
> 
> Careful; @reason can have values that are outside the range of a
> TpConnectionStatusReason (and in principle, so can the statuses!). Will g-i and
> Vala cope?

Yeah, they'll cope. It'd be nice to stick to the symbolic types, but there's an
outstanding Vala code generator problem dealing with Handle, so I already have
to sort that out in my application code.

> > - * @handles: (array length=n_handles) (element-type uint): An array of handles
> > - *  of type %TP_HANDLE_TYPE_CONTACT representing the desired contacts
> > + * @handles: (array length=n_handles) (element-type TelepathyGLib.Handle): An
> > + *  array of handles of type %TP_HANDLE_TYPE_CONTACT representing the desired
> > + *  contacts
> 
> Having a handle not be a uint would be a massive compatibility break anyway,
> and TpHandle is just a typedef for guint. Is this a functional change, or just
> for documentation?

The goal was to be able to use Handle everywhere, but it's already got the
problem mentioned above. So this isn't a big deal.

> It seems that Danni specifically annotated this to be of element type uint:
> deleting the element-type annotation ought to make it be Handle automatically.
> Ask Danni whether annotating it back to Handle will break Python/JS?

It's fine to have this be a uint.

The net result was I just removed this last patch (just required some trivial
changes to libfolks to handle it).

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