I am very grateful you put that tutorial together. It helped clear up many points for me
I would say the most important documentation to start with would be a very detailed account of how to set up the development environment. Especially with the removal of KDESudo and the new look QTCreator. Also a look at what the difference is between native and 3rd party drivers. Am I developing a 3rd party or a native driver ? I have no idea. And which should I produce ?
Then for both client and driver developers a detailed look at how the messaging between them occurs. I don't mean at the protocol level that indiserver implements but at what that means for developers. For a driver what functions get called by a client and when. Can a driver send a message to the client at any time etc etc. So some practical examples with diagrams as to how this all works. For example a diagram of what the server sends to a driver when it connects. When does the does the driver creator function get called ? When does the initproperties function get called etc etc. So a timeline drawing of how the client, indiserver and driver interact during the initial connection, for the interactions during normal operation and finally during shutdown.
I know that the project is very focussed on error free communication, that is obvious from the sample code. However it does not make the sample code easy to read when a large part of the functionality is built into the condition statement of an If Else. Much more readable would be to separate that out. So the functionality sets a local variable to true or false which is then tested. The conditions that have double negatives in them are even words. I know this makes for elegant code that shows off the skill of the programmer as to how much he can get done in a single line, but for a C++ newbie it means 10 minutes deciphering a single line of code !
I would suggest some code with no error checking is published. Not for operational use of course but to make the basic program flow easier to understand. Then a version with error checking included but in the simple manner I describe above, and then the preferred final version. Only then can the student get their head around the flashy code that the best programmers can write
All this could be done in a simple driver that just talks to an arduino or some such device to get and set a single value and display it. Maybe with a switch element as well. Then the student can play with everything they need to know. It's all very well having tutorials that don't talk to a real device but that leaves a steep learning curve as to how to actually do serial communications with the hardware for which it seems Indi has some useful functions.
I was also very confused about where everything gets put in the development environment. I wound up with the source code, a build folder and I was never sure where the installed code I was writing got run from. I wound up with multiple binaries of my driver and didn't have a clue which one was actually being used when I invoked them from EKos to try and debug. I would up always changing a bit of text in my code, like the name of the driver, so I could see from the client what was being actually run.
And that's before we get onto XML files, where they go and if I need one for my driver for Indi to see it.
So a map of where all the files go during the development process on a standard Linux machine and what are being run when would really really help.
Hope this helps, if it sounds confused it's because I am