Bug 70731

Do we care about CM-side introspectability yes? I'm pretty sure the mixin pattern won't be introspectable anyway, so we have to change that completely... I think we'll have to do like TpBaseContactList: an abstract GObject instead of GInterface. This is also how GDBus works afaik.

(In reply to comment #1)
> Do we care about CM-side introspectability yes? I'm pretty sure the mixin
> pattern won't be introspectable anyway

I have some ideas in that direction which I looked into yesterday. I think we can get quite a long way with signals.

(In reply to comment #1)
> Do we care about CM-side introspectability yes?

We'll never know how close/far we are unless we try it :-)

Created attachment 87997 [details] [review]
[WiP] TpBaseProtocol: be a little more tolerant of faulty  get_parameters()

It doesn't work from Python right now.

---

I still haven't been able to get it to work; this turns a critical + crash into just the critical.

Created attachment 87998 [details] [review]
TpBaseConnectionManager: add dup_cm_dbus_name() virtual  method

Subclasses written in PyGI can't override a field, but they can
override a virtual method.

---

This makes me sad, but I think it's necessary.

Created attachment 87999 [details]
TpCMProtocolSpec: name a parameter

gobject-introspection complains about it.

---

Or we could probably just (skip) TpCMProtocolSpec, tbh - it's deprecated in favour of TpBaseProtocol. Still, this is harmless.

Created attachment 88000 [details] [review]
[WiP] TpBaseProtocol: add missing transfer annotations

---

This is wrong, now I think about it: the a{sv} should be (transfer container) (element-type utf8 GValue) instead.

Created attachment 88001 [details] [review]
TpProtocolAddressing: add to the header

---

It can't be introspected otherwise. No point in documenting it, though.

Created attachment 88002 [details] [review]
[WiP] Introspect TpBaseConnectionManager and TpBaseProtocol

---

We shouldn't actually merge this until there's a "working" CM (it doesn't have to return a functional TpBaseConnection, it could just be a stub) with reasonable coverage.

Created attachment 88003 [details] [review]
[WiP] Add more pseudo-doc-comments to teach g-i about  TpBaseProtocol

---

g-i wants this Class::vfunc syntax which, as far as I'm aware, gtk-doc doesn't use for anything. :-(

The text is basically copypasta from tp_base_protocol_get_parameters(), etc.

Again, no merging until it, you know, works.

Created attachment 88004 [details] [review]
[WiP, doesn't work] make Protocol.Parameters introspectable

---

As far as I can see, this ought to work, but I can't seem to persuade g-i to override either cls->get_parameters or cls->get_parameters_array with a Python or JS implementation. If you can see what I'm doing wrong, please say.

Inability to override cls->get_parameters is understandable: the calling convention is pretty awkward for an interpreted language (it wants a flattened array of relatively complicated structs) so I would understand if g-i, gjs or pygi took the "not going to need it" approach. So I tried turning those structs into a backwards-compatible boxed type in a GPtrArray.

However, I can't seem to override get_parameters_array either - the implementation remains set to tp_base_protocol_default_dup_parameters_array, which is no good to me.

Created attachment 88005 [details] [review]
[WiP, doesn't work] Python and JavaScript CMs

---

The Python version currently says do_dup_parameters_array() because I tried making it (transfer full), but that didn't work either.

(In reply to comment #11)
> As far as I can see, this ought to work, but I can't seem to persuade g-i to
> override either cls->get_parameters or cls->get_parameters_array with a
> Python or JS implementation.

It turns out the problem is <https://bugzilla.gnome.org/show_bug.cgi?id=710665>.

I now have a sort-of-working Python CM with a Protocol. No Connections yet, obviously, but it's a start.

One nasty limitation is that if you raise a Python exception from a vfunc, PyGI just writes to stderr, and returns failure with no GError set; so trying to implement Tp.BaseProtocol.normalize_contact() is somewhat doomed, because we don't know how to fail.

It was a useful experiment, anyway...

http://cgit.freedesktop.org/~smcv/telepathy-glib/log/?h=introspectable

and following on from it (unknown status, I forget how far I got with this - but it doesn't make a TpHandleRepo so it can't be very far):

http://cgit.freedesktop.org/~smcv/telepathy-glib/log/?h=wip-introspectable-connection

-- 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/116.