GNOME Bugzilla – Bug 706907
gjs can't handle GHashTable/GArray/GPtrArray as a property in a GObject
Last modified: 2016-04-14 22:22:56 UTC
Created attachment 253284 [details] Test case for using GHashTable as a GObject property When I try to access my GHashTable property in my custom, introspected GObject, I encounter this error: "Error: Unable to introspect element-type of container in GValue" It might come from gjs_value_from_g_value_internal, where in a switch statement, GHashTable, as well as GArray, GPtrArray, and GByteArray are explicitly checked and not supported. Is using a GHashTable as a GObject property a design flaw perhaps, or is it just something that gjs doesn't support yet, or is it an issue with introspection (the object is made in Vala)? Is there any known way to access this GHashTable? Specifically, GXml uses a GHashTable property for GXmlNodes/GXmlElements to store named GXmlAttrs in, and makes that GHashTable available to the user, and I'd really like to make that available to Javascript users. If there's some way to override the attributes property and return a JS Object just in JS instead, I could perhaps do that. Here's a test case. Any advice would be welcome. If it's just a matter of adding support to gjs to somehow handle GHashTable properties, and you can offer some advice on how to implement it properly, I could perhaps write a patch for that.
While some argue that using GHashTable in the public API is a bad design choice, it is supported by gobject-introspection, if the right annotations are added (this is for C, I don't know about vala). OTOH, gjs does not use g-i annotations for properties, it uses the run time information from GValue/GObject, so it's just a matter of adding the support to gjs.
updating summary; it can't handle GPtrArray either, which we are using in NM now. (Though also, FTR, gobject-introspection didn't allow annotating the element type of GPtrArray-valued properties until g-i 1.42/GNOME 3.14, so it's presumably not being widely used.) See also bug 655189, which adds a tiny bit of support for using typelib information with object properties.
For GXml 0.6, I've ported most classes to use libgee collections. I've changed API to access them as GObject and Gee collections of them. Now you can get access to this object properties, but, may be you fall in GObject Introspection lack support for Vala's generics bug #639908.
For GXml 0.8/0.10, you have to implement your own serialize/deserialize methods, based on property's type, this allows you to use any type as property, just check at tests cases on /test, to find how or contact GXml mailing list. Any way, if you use Gee collections, you can use to_array() and define new methods to tell Introspection what is the type of your value. This is: using GXml; public class ExampleClass : GXml.SerializableObjectModel { public ExampleClass.with_values (int i, string s) { Object(Int : i, Str : s); } public int Int { set; get; default = 0; } public string Str { set; get; default = ""; } public override string node_name () { return "Example"; } public override string to_string () { return "ExampleClass"; } public class Array : GXml.SerializableArrayList { public new ExampleClass get (int index) { return base.get (index); } } } then this makes happy GObject Introspection, due to you are not using Vala generics any more, and by default call your new get method instead of Gee.ArrayList.get(), returning the correct object type.
Please close this bug.
Thanks for following up.