API documentation / structure

[not-my-profile]

Looking at the rustdoc documentation my thoughts are the following:

• The example on the main page is too long ... either shorten it, or move it into a submodule or just reference the examples in the examples/ directory.

• The structs and enums in the top-level namespace are all rather randomly jumbled together ... making it very hard to grasp the API from looking at its documentation. I think it would be better to make modules public rather than pub useing all these structs / enums in lib.rs.

• Seeing things like InternalEvent and InternalLifeCycle makes me question why these are exposed in the public API in the first place ... in any case they should probably not be in the top-level scope.

• In general I think the code could use some more structure ... e.g. the command and event modules are currently on the same level, begging the question what the difference between commands and events is. Looking into it Command appears to be part of an Event variant, so I think it would make sense to move the command module under the event module (same with the mouse module which currently only contains the MouseEvent enum).

[PoignardAzur]

Thanks for your feedback!

The example on the main page is too long ...

Good point. I still want to have an end-to-end example, but it should probably be shorter.

The structs and enums in the top-level namespace are all rather randomly jumbled together ... making it very hard to grasp the API from looking at its documentation.

This might not be ideal for documentation (though that's a matter of taste), but I'd rather have a flat import structure. The only modules I intend to have are widgets and commands which will be special "lists of stuff" modules. Everything else will be imported from the root.

Seeing things like InternalEvent and InternalLifeCycle makes me question why these are exposed in the public API in the first place ... in any case they should probably not be in the top-level scope.

Those are going to be removed in a future refactor.