Feature/adding docstrings

[fullcontrol-xyz]

Wow, nice work! I'll look at this ASAP. From a quick look, it seems good. Have you checked that these are good/logical for the end user designing in FullControl? I.e. are these expected/tested to be as good or better than the original docstrings for intellisense?

[fullcontrol-xyz]

Also, with regards to renaming tutorial notebooks directory from docs to tutorials... is this just for clarity for end users?

There may be some issues currently. The links within them and readme files will need updating to point to tutorials instead of docs. Similarly for the scripts in 'bin' that converts notebooks/models to colab versions. There may be other considerations too. Shall think about it all.

Thanks for your work on this!!

[miwaniza]

The main consideration in renaming docs to tutorials is that Sphinx usually using docs as a working dir for the documentation. The alpha version of documentation: readthedocs.io

[fullcontrol-xyz]

Gotcha, it does make sense that the tutorial notebooks are conceptually different from docs.

That's awesome to have the docs put together nicely.

Is it possible to have two versions? One that documents everything in FullControl (like the version you shared), which is great for the more technical people, and one that only describes the functions that are exposed to the regular designer when the import fullcontrol as fc. Those designers only need to know about maybe 10% of the things in the current docs. And/or is there a way to collect appropriate things together. E.g. All the state objects together, all the geometry functions together, etc.

I'm thinking that the code in my geometry tutorials notebook eventually needs to be separated into individual mini docs, so that someone can easily add a new geometry function and some demo code for it. Maybe I'm overcomplicating things and those people should focus on good doc strings rather than a coded example. But for the regular user, it's really valuable to see an image of the geometry rather than just the function name. I understand that this may be a completely separate avenue of documention to what you've done here and love your thing even if it won't have all that functionality. But, in the end, would you see the readthedocs stuff also having code examples?

Thanks again!

[fullcontrol-xyz]

Also, some bits of lab would be great to include in docs (geometry stuff). I don't think they are yet. The multiaxis stuff in lab is likely to change considerable in the near future, and may be confusingly duplicatory of the classes in the main FullControl directory, so can see them being excluded for now

[miwaniza]

I'm going to use the structure like below, where guides will be your ipynb files converted to md or rst format.

docs/
├── source/
│   ├── api/
│   ├── guides/
│   │   ├── getting_started.rst
│   │   ├── advanced_features.rst
│   │   └── troubleshooting.md

Later, more detailed documents can be placed there.

[fullcontrol-xyz]

So it's fine if the interactive guides will change to a large number of tiny interactive notebooks (just one code cell in many cases - as I intend), which are accessed through overarching contents guides or similar (just to map them out), and then those individual guides will converted to md or similar for this? Perhaps with a link to the interactive notebook for interested users...