That is true, if a method doesn't have its own docs (like most constructor), it's not worth putting them at the forefront of the documentation.
This will remove a lot of unnecessary text from the current docs.
For example, Efl.Ui.Button (here) will have an empty Public methods section.

Are you sure you are not meaning with the second kind the overrides and implements that have a special documentation ?

Regarding how to render inheritance, let's recap:

Just from the top of my head:

• Right now there is this short version of "Inheritance" that starts with the parent class. I think it would be nice to have there as well the list of interfaces and mixins that are directly inherited, just with a link so you can click on it.
• Maybe we can join the Inherited section with the event section, it feels akward to me to have them doubled.
• The Members are kind of very "short" if this list gets shorter due to bullet point 2, we could make something that is a little bit more "verbose" telling what the members are etc.
• The Titles in the property view could get links to jump back to the widget they are on.
• The idea from k-s http://i.imgur.com/EINws0S.png to have something like "C usage" also looks very very nice, maybe something to consider ?
• I get the navigation bar on every site, is it possibleto turn it off, its a little bit out of place here.
• And a bug, taking https://www.enlightenment.org/develop/api/efl/ui/collection and clicking on Efl.Ui.Multi_Selectable.select_mode will not redirect you to a valid page.

Thank you for your reply! Now I understand your point and I agree with you.

• NOW : radius_get { } for Efl.Canvas.Gesture_Zoom
• TODO : @property radius { get { } } for Efl.Canvas.Gesture_Zoom

I'm not talking about Efl.Canvas.Gesture. This one is OK. I'm talking about the derived classes: Efl.Canvas.Gesture_Flick, Efl.Canvas.Gesture_Zoom, etc.
Some of these derived classes have methods called *_get, which look to me like they should be readonly properties.

Their fields should be read-only properties instead of methods. This is more natural for bindings.

Do you mean that EITHER Efl.Canvas.Gesture provides read-only properties OR Efl.Canvas.Gesture's setter methods / writable properties should not be public?

I'm OK either way as long as everything is properly documented. Tuples+D10889 looked OK but I haven't looked at the current API using indexers yet.

Creating a new class for each tuple return does look more complicated than it needs to be IMO. However, with indexer, we are already creating new classes anyway, so maybe it could be worth it?

That's what I was thinking of, yes. And I also agree it looks unnecessarily complicated.

Looks like we should not be using tuples as return values after all. It is recommended to use a explicit class, with proper fields and docs.

We should do something about this, docs are incomplete right now.

Correction: automatic documentation does reference sometimes beta classes, producing broken links.
For example, in the Full Hierarchy table.

OK, the files corresponding to BETA classes were old remnants which should have not been committed. Already removed them.
Please ignore this task.