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 728236 - type annotation example for gobject properties needs work
type annotation example for gobject properties needs work
Status: RESOLVED OBSOLETE
Product: gobject-introspection
Classification: Platform
Component: docs
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks: 727778
 
 
Reported: 2014-04-15 06:40 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2015-04-18 09:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stefan Sauer (gstreamer, gtkdoc dev) 2014-04-15 06:40:07 UTC
https://wiki.gnome.org/action/show/Projects/GObjectIntrospection/Annotations#G.28S.29List_contained_types

has two examples that need review:
= FooBar:alist: (type GSList(NiceObj)) =

1) GSList(NiceObj) is not a type, alternatives:
   a) (type GSList<NiceObj>)
   b) (type GSList)(element-type NiceObj)
I prefer a) as it scales (consider GList<GArray<String>>)

2) we must not nest '()'. The annotations are parsed in gtkdoc using regular expressions. I can make this example work for annotation on the symbol-name level as there is no text following, but on parameter descriptions, matching extra '()' inside the annotation would require a handwritten parser.


= Returns: (element-type Gtk.Widget) (transfer container): List of #GtkWidget =
We should document on this page what TYPE means. Gtk.Widget reads well on the bindings level, but this notation is not consistently used. If we go this way should the property example be: (type G.SList<Nice.Obj>)?
Comment 1 André Klapper 2015-02-07 17:18:22 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Comment 2 Dieter Verfaillie 2015-03-24 20:09:51 UTC
(In reply to Stefan Sauer (gstreamer, gtkdoc dev) from comment #0)
> https://wiki.gnome.org/action/show/Projects/GObjectIntrospection/
> Annotations#G.28S.29List_contained_types
> 
> has two examples that need review:
> = FooBar:alist: (type GSList(NiceObj)) =
> 
> 1) GSList(NiceObj) is not a type, alternatives:
>    a) (type GSList<NiceObj>)
>    b) (type GSList)(element-type NiceObj)
> I prefer a) as it scales (consider GList<GArray<String>>)

No, the wiki page is correct as (type GSList(NiceObj)) is the agreed upon syntax.

> 2) we must not nest '()'. The annotations are parsed in gtkdoc using regular
> expressions. I can make this example work for annotation on the symbol-name
> level as there is no text following, but on parameter descriptions, matching
> extra '()' inside the annotation would require a handwritten parser.

I asked around about this 3 years ago on irc and in https://bugzilla.gnome.org/show_bug.cgi?id=676133#c17
when I tried to end the madness and make g-ir-scanner understand the
actual real GTK-Doc comment block format. I was told on multiple
occasions not to use angle brackets for the (type) annotation, but
to use nested parens instead. Indeed resulting in the need to drop
some regexes and use a parser-ish beast:
https://git.gnome.org/browse/gobject-introspection/tree/giscanner/annotationparser.py#n1861

Note g-ir-scanner still accepts angle brackets for backward compatibility
reasons:
https://git.gnome.org/browse/gobject-introspection/tree/giscanner/annotationparser.py#n1788

So, I don't know if we need to be in a hurry to go and change this
back to angle brackets, 3 years after deciding on parens?
Maybe we should first decide and document the actual correct
agreed upon GTK-Doc syntax for this once and for all...
Well, this and other details, see https://bugzilla.gnome.org/show_bug.cgi?id=676133#c42 ;)
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2015-04-18 09:31:39 UTC
I'll give up here. I made the () work, but this will likely cause issues when there are multiple annotations on a symbol.