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.

It could be that these classes are currently unused, yes. @cedric should know. @cedric?

@segfaultxavi
I tried to improve descriptions for efl_loop_message_future.eo and efl_loop_message_future_handler.eo.
They look like actually unused, though.
I mean they are created and assigned but there isn't a place that accesses or call some apis to those things.
Am I wrong?

This has been sitting here for a month and we need to do something about it, because the current state is not ideal:
The C# generator automatically adds docs to properties saying "The default value is X", taking that value from the the EO file.
But the truth is that implementations are free to use any default value they please, regardless of what the EO file says.
Default values currently in the EO files were chosen to match the implementations, but it is almost guaranteed that they will fall out of sync in the future.