GNOME Bugzilla – Bug 786863
Introspection in Gjs fail to boxing some opaque objects while Python not.
Last modified: 2018-01-27 12:05:16 UTC
Is really annoying to see that we can not access to a function using introspection inside Gjs in some context, while we can access using python. I think, if in python this is possible, probably there are a way to handled this types of problems inside Gjs. An example also inside a gnome library can be found here: https://bugzilla.gnome.org/show_bug.cgi?id=783578 Not matter who cause it, or if it is the right or the wrong way to provide the introspection to a library, because in Python there are not a problem to access the opaque structure. I think then this is a problem in both sides then
Ok, the specific case where gjs complains is this structure: typedef struct { char *profile; char *human_profile; char *status; guint priority; guint n_sinks, n_sources; } GvcMixerCardProfile; This is not registered as a boxed type, and gjs fails to handle it as a raw structure because of the pointer fields. The proper solution is to register the structure as a boxed type (with a copy and a free function) in libgnome-volume-control. Failing that, gjs can provide a default copy/free operation because the struct is only produced by a (transfer none) function, so gjs only needs to free its own allocation (and therefore it can safely g_free each pointer and g_free the whole structure). This is probably what pygobject does. Such a change would probably boil down to saying that UTF8 and FILENAME types can be "allocated directly" (gi/boxed.cpp:954), and then putting g_strdup/g_free in the right places. (OTOH, if the struct was returned as (transfer full), g-ir-scanner would complain with "Invalid non-const return of bare structure or union, register as boxed type or (skip)")
Thanks for take in consideration this issue. Independent of if this is an error in libgnome-volume-control, if there are a fix to this type of things in gjs will be really good. In libgnome-volume-control is not the only place where i encounter the same situation, for example this work in python: Gio.io_extension_point_register while not in gjs (i think because of the same reason). Is another opaque object: https://lazka.github.io/pgi-docs/Gio-2.0/classes/IOExtensionPoint.html#Gio.IOExtensionPoint Be sure, is not this two cases only. Python is a programming language that is used for a lot of developers. Then they use python to ensure the introspection support in his own libraries. If there are introspection in python, they think all will be ok and then we clashed with the problem when we use gjs. So, regardless of what we can do with libgnome-volume-control, having the same thing as python would avoid headaches, unnecessary reports in the future and the assurance that everything works the same way regardless of programming language.
-- 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/gjs/issues/109.