Add documentations #12

New Issue

kazhnuz · 2020-08-09T11:10:22+02:00

kazhnuz commented

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

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

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

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

( 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

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

Sign in to join this conversation.

No Milestone

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: epervier/epervier-old#12