Re: where to find GIR XML documentation?

[Phil Clayton <phil clayton veonix com>]

girepository has an abstract model of types.  g_type_info_get_tag gives 
the type tag.  If the tag is G_TYPE_TAG_INTERFACE, 
g_type_info_get_interface gets the interface.  If it is 
GI_TYPE_TAG_ARRAY, g_type_info_get_array_* and 
g_type_info_is_zero_terminated can be used to get array information.  If 
it is a container tag, e.g. GI_TYPE_TAG_ARRAY, GI_TYPE_TAG_GLIST etc, 
g_type_info_get_param_type can be used to get the element type information.

On 19/02/19 18:37, Tony Houghton wrote:
> I don't think parsing the gir XML to generate static-typed bindings is 
> easier than using the typelib API. Although it doesn't use GObject, it 
> is introspected, so it can be used from python etc. Some important 
> information is awkward to extract from the XML, and the API has methods 
> that make it easier. The trouble is, without being able to get a 
> typename from a GITypeInfo associated with an argument or return value 
> the API isn't much use for languages with strict typing. Or is it 
> possible to get a typename by using g_base_info_get_attribute()?
>
> On Tue, 19 Feb 2019 at 17:12, Emmanuele Bassi <ebassi gmail com 
> <mailto:ebassi gmail com>> wrote:
>
>     The typelib is just as an intermediate format as the GIR; it only
>     makes sense under the semantics of the particular language that uses
>     libgirepository, and it exists only because loading XML every time
>     you load an application written with a non-C language is an
>     unacceptable performance penalty.
>
>     Improving the typelib is basically pointless for non-dynamic
>     languages; parsing the GIR and querying the binary blob—which, by
>     its own design, does not represent the extracted GIR data 1:1—in
>     order to generate code is basically the same operation, except it's
>     easier to parse XML than it is to use libgirepository's C API.
>
>     Stabilising and formalising the GIR format is a better effort, at
>     this point; the typelib binary blob generated by g-ir-compiler would
>     benefit from that effort just as well as any tool that does code
>     generation starting from the XML.
>
>     Ciao,
>       Emmanuele.
>
>     On Tue, 19 Feb 2019 at 16:48, Jasper St. Pierre
>     <jstpierre mecheye net <mailto:jstpierre mecheye net>> wrote:
>
>         Hi,
>
>         Unfortunately, the GIR XML is basically an intermediate product,
>         and unless you implement the same algorithms as the GIR typelib
>         compiler, you won't end up matching the same semantics. You can
>         see this in places where we count the number of '*' characters
>         in the c:type as a heuristic [0]. I don't think anybody would be
>         against improving the GIR XML to make things more high-level and
>         have more meaningful semantics, but I think improving the
>         typelib is going to be more fruitful, since it comes after all
>         the processing that the GIR compiler also does.
>
>         [0]
>         https://gitlab.gnome.org/GNOME/gobject-introspection/blob/master/girepository/girparser.c#L2034
>
>         On Tue, Feb 19, 2019 at 5:38 AM Tony Houghton <h realh co uk
>         <mailto:h realh co uk>> wrote:
>
>
>             On Tue, 19 Feb 2019 at 09:40, Philip Withnall
>             <philip tecnocode co uk <mailto:philip tecnocode co uk>> wrote:
>
>                 On Tue, 2019-02-19 at 17:26 +1100, David Bellot via
>                 gir-devel-list wrote:
> >                 Hi,
> >
> >                 I'm looking for a complete description of the GIR xml
> >                 format. The website is a bit outdated and misses a lot
> >                 of documentation (or at least it's my impression).
>
>                 https://developer.gnome.org/gi/stable/gi-gir-reference.html
>                 is the best I know of, but it’s pretty thin and you
>                 probably found it in the docs/ directory instead.
>
>
>             https://developer.gnome.org/gi/stable/index.html and
>             https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations
>             are helpful for summarising what sort of information should
>             be available in each type of node, but unfortunately there's
>             no direct mapping between the three types of representation.
>
>                 Why do you need a description of the XML format?
>                 Typically, using the GIR utilities means you don’t need
>                 to know the XML format.
>
>
>             Parsing the XML seems to be the only way to generate good
>             quality static definitions for a typesafe language eg Java,
>             Kotlin, Typescript. For a start there are a few useful
>             immediate children of the root node that you can't read with
>             the typelib API (eg C headers, pkg-config package name). But
>             most of all, GITypeInfo doesn't contain a type name (calling
>             g_base_inf_get_name() on a GITypeInfo causes an abort!). So
>             any function definitions in the target language would have
>             argument and return types limited to primitive types, opaque
>             pointers, generic GObjects and other generic boxed types.
>
>             -- 
>             TH
>
>             _______________________________________________
>             gir-devel-list mailing list
>             gir-devel-list gnome org <mailto:gir-devel-list gnome org>
>             https://mail.gnome.org/mailman/listinfo/gir-devel-list
>
>
>
>         -- 
>            Jasper
>         _______________________________________________
>         gir-devel-list mailing list
>         gir-devel-list gnome org <mailto:gir-devel-list gnome org>
>         https://mail.gnome.org/mailman/listinfo/gir-devel-list
>
>
>
>     -- 
>     https://www.bassi.io
>     [@] ebassi [@gmail.com <http://gmail.com>]
>
>
>
> --
> TH
>
>
>
> _______________________________________________
> gir-devel-list mailing list
> gir-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gir-devel-list