| Summary: | methods returning GStrv aren't introspectable | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Simon McVittie <smcv> |
| Component: | tp-glib | Assignee: | Simon McVittie <smcv> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | kai.huuhko |
| Version: | git master | Keywords: | patch |
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | review+ | ||
| i915 platform: | i915 features: | ||
| Attachments: | Annotate GStrv as (array zero-terminated=1) for introspectability | ||
Created attachment 57475 [details] [review] Annotate GStrv as (array zero-terminated=1) for introspectability (type GObject.Strv) isn't understood. This affects tp_account_update_parameters_finish, tp_connection_manager_dup_protocol_names, tp_connection_manager_protocol_dup_param_names and tp_protocol_dup_param_names. (In reply to comment #0) > Open question for reviewers: should we take this opportunity to apply "Rename > to: get_foo" to the affected dup_foo() methods ... ? No, we shouldn't, because that doesn't work unless get_foo() also exists. Comment on attachment 57475 [details] [review] Annotate GStrv as (array zero-terminated=1) for introspectability Review of attachment 57475 [details] [review]: ----------------------------------------------------------------- Go go go. Fixed in 0.19.0 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
16:40 < kuuko> Is the tp-glib function tp_connection_manager_dup_protocol_names() named differently when accessing it from python? It turns out it's not accessible at all, because (type GObject.Strv) isn't understood. TpConnectionManager.protocols isn't understood by introspection, so that's no help either. Open question for reviewers: should we take this opportunity to apply "Rename to: get_foo" to the affected dup_foo() methods, and should we apply that annotation to dup_foo() methods in future? The get/dup duality isn't really relevant for g-i.