Add documentations

kazhnuz commented

2020-08-09 11:10:22 +02:00

Owner

For now, nearly no function or object is documented. This situation is highly problematic as it’ll need more documentation and examples. For the moment, the only way to learn to use gamecore is to read directly the source.

To answer that problem, add a way to automatically generate documentation

For now, nearly no function or object is documented. This situation is highly problematic as it’ll need more documentation and examples. For the moment, the only way to learn to use gamecore is to read directly the source. To answer that problem, add a way to automatically generate documentation

kazhnuz added the

0. Imported

label 2020-08-09 11:10:22 +02:00

kazhnuz commented

2020-08-09 11:10:31 +02:00

Author

Owner

Dox seems a good candidate to generate the documentation.

[Dox](https://github.com/CentauriSoldier/Dox/) seems a good candidate to generate the documentation.

kazhnuz added

3. Need investigation

and removed

labels 2022-08-08 13:53:50 +02:00

kazhnuz commented

2022-08-08 13:58:16 +02:00

Author

Owner

LDoc seems better maintained.

One big issue seems to be that every modules seems to be stuck together. It would be better to be able to classifies them.

The possibilities here are:

Use the manuals for giving more complexes explainations
Use "functions" to handle utils
Use "class" to handle classes
Try to use new_type to see if we can separate the core and stuff.
Put our "modules" as top-level elements of the framework, and use them with "new_type" to see if it works. Else use "submodules" whenever we can and have gigantic pages ?

If we have just one module categories, the ideal would be to have something like

- asset
- asset.yyy
- asset.vvv
- core
- core.xxx
- core.yyy
- scene
- scene.transitions
- scene.world
- scene.world.camera
- scene.gui

( honnestly even without that, this organisation seems better than our horrible "module" big folder... )

LDoc seems better maintained. One big issue seems to be that every modules seems to be stuck together. It would be better to be able to classifies them. The possibilities here are: - Use the manuals for giving more complexes explainations - Use "functions" to handle utils - Use "class" to handle classes - Try to use new_type to see if we can separate the core and stuff. - Put our "modules" as top-level elements of the framework, and use them with "new_type" to see if it works. Else use "submodules" whenever we can and have gigantic pages ? If we have just one module categories, the ideal would be to have something like ``` - asset - asset.yyy - asset.vvv - core - core.xxx - core.yyy - scene - scene.transitions - scene.world - scene.world.camera - scene.gui ``` ( honnestly even without that, this organisation seems better than our horrible "module" big folder... )

kazhnuz commented

2022-08-08 14:00:54 +02:00

Author

Owner

( The "create the manual" part will be done post-0.7.0 )

kazhnuz added this to the epervier 0.8.0 (beta 1) milestone 2022-08-09 08:36:31 +02:00

kazhnuz commented

2023-02-27 12:22:03 +01:00

Author

Owner

An important thing would be to know which class needs to be "visible" and APIs and which would be invisible.

kazhnuz removed this from the epervier 0.8.0 (beta 1) milestone 2024-11-04 12:04:19 +01:00

Add documentations #12