Tim replied to the topic 'Returning to ASCOM' in the forum. 1 year ago

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 :)