http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/commit/?h=gdbus-all&id=999bb8479dbc6a21c72b5c927097969c2abeeecd

Can't we create the skeleton in _init() and so not break registering while creating the object?

If not, add a g_return_if_fail() in tp_base_channel_register() checking that the skeleton exist to catch migration bugs?


http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/commit/?h=gdbus-all&id=9d18ffa6de783ccf7ad13dfda68093ef7773a007

+    case PROP_N_CONNECTIONS:
you forgot the 'break'


http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/commit/?h=gdbus-all&id=279930af369137e22c4e5a61e1a3b7ea33b389bc

Is that really the proper way to do it or just a workaround for this gjs bug?

I'm not really familiar with the handle repos code so I'd prefer to let smcv review those from a high level pov.

http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/commit/?h=gdbus-all&id=179a0a50cc58cc384b15060f4643959d3c62f820

Please add a one line comment at the start of each file explaining what is being demonstrated in the example.

Shouldn't the first one be in examples/client/js/ ? I'm not convinced this example is that useful actually. examples/ is supposed to contain scripts showing how to use the TP API to perform common tasks.
Here it relies on a fake CM (while the other examples can be used with real connections) and use low level API users are not supposed to care about. And we already have examples/client/js/contact-list.js displaying contacts.

The second example makes much more sense as it show how to write a simple CM in JS.


http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/commit/?h=gdbus-all&id=01f8b280742a67260b4ea542127d761b56f8fda5

Why can't we have (transfer non) vfuncs?

See also

https://bugs.freedesktop.org/show_bug.cgi?id=77194 (contains partial review of an earlier version of this branch)
https://bugs.freedesktop.org/show_bug.cgi?id=77197 (likewise)
https://bugs.freedesktop.org/show_bug.cgi?id=29265 (can maybe be closed as a dup when this is merged?)
https://bugs.freedesktop.org/show_bug.cgi?id=70731 (WiP, partially duplicates this branch, might be worth skim-reading commits and comments)
https://bugs.freedesktop.org/show_bug.cgi?id=71508 (included in this branch)

I am not particularly happy with the TpPresenceStatusSpec API that I wrote for Bug #71508, which Xavier has included in this branch. If you can think of better APIs for dealing with TpPresenceStatusSpec, I'd like to hear them.

I think TpPresenceStatusSpec should perhaps be a GObject - that way, if CMs want to attach arbitrary misc to it (the names of XMPP statuses or the numeric values of some enum in libpurple, perhaps), it has qdata with which they can do that.

(In reply to comment #1)
> I'm not really familiar with the handle repos code so I'd prefer to let smcv
> review those from a high level pov.

Noted.

> Why can't we have (transfer non) vfuncs?

Imagine you're pygobject. You call the Python implementation of a vfunc and get a Python unicode object (which is in UTF-16 or UCS-4), or a Python list, or something. You know that what you are required to return to C code is a const char * in UTF-8, or a GList, or something.

OK, fine, you can encode the unicode object to a string, or make a GList containing C equivalents of each element of the Python list. But when can you free that string, or free that GList? The answer is "you can't know" - maybe the API docs for the C vfunc even say you have to return a string that is valid forever?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-glib/issues/130.