GNOME Bugzilla – Bug 384579
Support more typedefs
Last modified: 2018-05-22 13:01:02 UTC
Please add support for defining types like this: typedef GtkHBox MyMagicHBox; typedef GtkHBoxClass MyMagicHBoxClass; Since the introduction of g_type_class_add_private() this can be used very widely to hide implementation details without private pointers.
We do support simple typedefs like this: typedef gint gboolean; Is the problem that we don't output things like signals and object properties? Looking at the code, it looks like we check every symbol to see if it has associated hierarchy/signals/properties etc. (in gtkdoc-mkdb.in line 573). So I'm not sure why it isn't working. It may just need a minor fix somewhere.
(In reply to comment #0) > Please add support for defining types like this: > > typedef GtkHBox MyMagicHBox; > typedef GtkHBoxClass MyMagicHBoxClass; It would be helpful if you said what kind of support you are missing... But let me guess... The typedef for "MyMagicHBox" appears in the XML DocBook source, it gets the same id "MyMagicBox" as the section, and xsltproc complains (this is the only problem I encountered when I tried it). And you don't want to change the section id you want to change the typedef instead. This can be perhaps detected somehow, or all typedef ids can be mangled to *-typedef. But I'm not sure it worths doing. typedef struct _MyMagicHBox MyMagicHBox; typedef struct _MyMagicHBoxClass MyMagicHBoxClass; struct _MyMagicBox { GtkHBox parent; }; struct _MyMagicBoxClass { GtkHBoxClass parent; }; does exactly the same as your example, it already works with gtk-doc, and I can't see any private pointers there (I'm not sure what you mean, but there are no pointers at all, so I suppose there are no private pointers either).
My point is that the approach with the struct is quite a lot stuff to write. I want people to be easily able to write their own canvas items for my canvas (which works perfectly with the one-line typedef given on top). They shouldn't have to bother with this struct aliasing.
(In reply to comment #3) > My point is that the approach with the struct is quite a lot stuff to write. If writing the six simple lines is something people cannot bother with, I wonder how they can bother with implementation of a new class in C at all. One has to follow quite a few conventions to let gtk-doc understand the code. Using struct nesting to express subclassing is one of them and it is the way Gtk+ code has been always written. > I > want people to be easily able to write their own canvas items for my canvas > (which works perfectly with the one-line typedef given on top). They shouldn't > have to bother with this struct aliasing. Mangling ids of typedefs (gint, gchar, ...) to make them different from section ids would create much more total ugliness than several struct aliasing somewhere. So I would say the question is not what you want but what you suggest?
Six lines less are sixe lines less with potential typos.
Please answer my question.
If it was trivial to support I'd add it, but otherwise I don't really think it is worth worrying about.
-- 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/gtk-doc/issues/4.