Self Documenting Tools

Any chance of getting the tools to self document? Potentially this allows using tool code to maintain https://docs.librecad.org/en/2.2.0_a/ref/tools.html in the manual.

If a reasonable template and instructions were set up then someone with a low level of expertise might be able to add the detail.

Previous discussion: https://librecad.zulipchat.com/#narrow/channel/122956-Codebase/topic/V3.20GUI/near/203240021

Well, you're right - there were several tools were added, so the end-user documentation becomes critical.

However, I'm not sure I understand what do you mean by "Self-document" - could you please expand on this?

I suspect that the only way to prepare user manual for features is .. well, just to write it. But probably I'm missing something there and you have something else in mind.

It would be best to refer to the previous discussion I linked about the implementation in LC3.

The scope would be the manual reference section tables (which don't contain any interpretation) ensuring all tools are documented. It's my understanding this is fairly basic contemporary programming. I'm thinking of https://peps.python.org/pep-0257/#what-is-a-docstring

I imagine the process would be to generate a table for each tool category (https://docs.librecad.org/en/2.2.0_a/ref/tools.html) containing Name, Icon, Command, Description. Maybe it could extend to toolbars and widgets. The documentation team could take it from there, and if the process was straightforward, might even be able to add the descriptions to the code with developer guidance.

johnfound wrote

...just proves my rule #2:
"In the software design, every list dreams to become a tree."

Yes, I've checked the discussion and well, yes, now I see your point...

Well, indeed, there are several tools for documenting the code (like Doxygen, QDoc, STANDARDESE, etc. - for C++, to name a few).

However, they are rather oriented to documenting of the "source code" - and therefore, they use such notions as "class", "header", "function" etc.  for making documentation.

Therefore, for producing the user manual - such a documentation on the source layer seems to be not (at least, directly) applicable. For example, some feature (or action) may involve lot's of files, functions, classes etc. and documenting them is too low-level and not informative for the end user.  

Therefore, I'm afraid the only way to go there - is just to create manual documentation for features.  

At least, right now I have no idea how to use the code documentation approach/tool to achieve some useful output...

With my merge request I usually add description for the added functionality (located here: https://github.com/LibreCAD/LibreCAD/tree/master/ChangeLogs), yet still it's quite brief to be useful for the end user.