TJF wrote:
AGS wrote:"record" I could find (in girtobac) but not "glib:boxed" (omitted on purpose I assume?).
I didn't find such a tag in any header.
In an earlier post I mentioned the difference between girwriter.c and girwriter.py.
girwriter.c has not been updated for over a year while girwriter.py has been
updated recently. Looking at the content of the .gir files I have (gtk3, gdk3)
I am pretty sure these files were generated by girwriter.py, not girwriter.c.
The Python code tag that tells me girwriter.py is the tool used
to generate .gir files looks like this
Code: Select all
if hasattr(node, 'doc') and node.doc:
self.write_tag('doc', [('xml:space', 'preserve')],node.doc)
There is no mentioning of a doc node in girwriter.c Meaning girwriter.c
cannot write a doc tag and cannot be the producer of the .gir files
I am using (as those files contain doc tags).
In your message you refer to the tags being sorted. girwriter.c does no
sorting so xml produced by girwriter.c has no sorted tags.
But as pywriter.py is used to generate .gir files tags are sorted
as pywriter.py does sort tags.
Regardless of pywriter.py sorting tags I still find tags are not (always)
sorted in the .gir files I am using.
Example.
File starts with (only relevant attribute shown)
Later on in the file I find a record tag followed by a bitfield tag
(at the same depth). record < bitfield making me think tags are not
(always) sorted.
I am going to stick with giwriter.c as it is very doable
to find out the .gir format by looking at the C code.
And because girwriter.c deals with attribute values like "GLib.List",
"GLib.SList" and "GLib.Array" in a special way.
girwriter.py just writes those attribute values without a change
(which explains how a .gir file can have both doc elements
and GList.Slist etc... attribute values).
Last but not least: the .gir format allows to add an arbitrary number
of attribute tags to an existing tag in a .gir file. The attribute tag that
can be added looks like
Code: Select all
<element name="attribute">
<attribute value="name"/>
<attribute value="value"/>
</element>
Using the attribute tag it would be possible to extend the .gir format.
An example usage could be a tag to denote some platform specific value
Code: Select all
<attribute name="platform" value="linux"/>
<attribute name="include_path" value="some_path"/>
<attribute name="platform" value="windows"/>
<attribute name="include_path" value="some_other_path"/>
Tags have a set sequencing so if there is an attribute tag then a check
for attribute value platform would be enough to continue parsing
either linux - related info or windows related info. Whether this kind
of use of the attribute tag is really usable I don't know. But at
least it will be possible to extend girtobac without breaking the
parsing of a .gir file that does not contain attribute tags
(at the moment girtobac does not recognize attribute tags).
Is there a reason for girtobac not handling some array related
attributes/attribute values in a specific manner?
(attribute "zero-terminated", attribute values "Glib.Array",
"Glib.PtrArray", "GLib.ByteArray").