After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 694115 - Folks unusable from JavaScript
Folks unusable from JavaScript
Status: RESOLVED OBSOLETE
Product: folks
Classification: Platform
Component: general
git master
Other Linux
: Normal major
: 0.12.x
Assigned To: folks-maint
folks-maint
Depends on: 639908 702490 703402
Blocks:
 
 
Reported: 2013-02-18 18:11 UTC by Travis Reitter
Modified: 2018-09-21 16:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Travis Reitter 2013-02-18 18:11:34 UTC
I tried writing some example JS code using Folks and hit an immediate road block: Gee structures' elements are inaccessible from JS. If you iterate over them, their elements just show up as "undefined" (effectively the same as "null").

This seems to be primarily due to bug 639908, but I'm opening this bug in case we find any other blockers along the way (and to make it more searchable).
Comment 1 Simon McVittie 2013-03-08 14:20:41 UTC
I wonder whether it would be worthwhile to add a parallel version of the problematic APIs solely for bindings, that returns a well-understood data type like GList?
Comment 2 Philip Withnall 2013-03-08 20:01:48 UTC
(In reply to comment #1)
> I wonder whether it would be worthwhile to add a parallel version of the
> problematic APIs solely for bindings, that returns a well-understood data type
> like GList?

I would be strongly against doubling the number of API entry points in folks and the large maintenance burden that would impose. Add to that the fact that GList is easy to misuse in Vala (creating leaks or use-after-frees), which is why we went with libgee in the first place.
Comment 3 Travis Reitter 2013-07-01 16:33:06 UTC
The core problem (bug #639908) still exists, but we've fixed some issues in the meantime: bug #702490, bug #703402.

With these in place (the latter pending review), Folks is usable enough from JS to read Individual/Persona details* and even use Tpf.Personas to initiate Telepathy chats, calls, etc.

* There is the major caveat that reading most Individual/Persona fields requires a shim Vala or C library to de(marshall) values stored in the many Gee structures we use (due to bug #639908). JS can get the pointer to, eg, persona.im_addresses, but that must be passed along to a shim library to pull out the details required by the JS code and return it in a format that JS can use (eg, a GArray of strings which will be automatically converted to a string array for use in JS).
Comment 4 Philip Withnall 2013-08-07 16:14:07 UTC
Does this require any more work on the folks side (assuming we don’t go with the suggestion from comment #1), or are we just waiting for a GIR miracle (bug #639908)?
Comment 5 Simon McVittie 2013-08-07 16:51:11 UTC
(In reply to comment #3)
> reading most Individual/Persona fields
> requires a shim Vala or C library to de(marshall) values stored in the many Gee
> structures we use

Isn't that just my suggestion from Comment #1, but copied into each g-i project that consumes Folks data? I'm not sure I see the advantage, tbh.
Comment 6 Philip Withnall 2013-08-08 11:36:21 UTC
(In reply to comment #5)
> Isn't that just my suggestion from Comment #1, but copied into each g-i project
> that consumes Folks data? I'm not sure I see the advantage, tbh.

Sort of, except the g-i projects would only shim the APIs they actually use, which I suspect might be a lot less than what folks provides.
Comment 7 GNOME Infrastructure Team 2018-09-21 16:01:00 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME'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.gnome.org/GNOME/folks/issues/54.