I've been working on a Rust-native client that has no dependency on libindi, specifically because I want something portable; in theory it would be quite easy to provide a Python extension with the Rust backend.
Having said that, a pure Python client would be much easier to write (I'm struggling with INDI because of the poor state of XML parsers in Rust) and in theory to maintain given the wider Python userbase. For client authoring it'd certainly be easier to work with. I'm writing this purely to drive an all-sky camera and that'll be shipping images off to a neural net/CV stuff for image segmentation, and Python's a native of that sort of thing.
I would be afraid that the Rust-based python extension would have similar problem..
Not that I don't trust your work, but given that not many people know Rust, it would be difficult to find someone helping you maintain it :\
Ideally, the best solution would be a simplified JSON interface written in C++ directly into the INDI server. That way, writing a client for python, or indeed any other language, would be much much simpler
I definitely agree that a full python solution would eventually be the best choice for long term support.
Cases where people will write exotic macros here and there that will probably continue break swig (without even considering the static binary dependency for the client)
That is good to know!
I was actually about to start my own implementation, but if I can find the time I might try to contribute to one of these.
geehalel implementation seems more mature, but also inactive in a couple of years. @Jean-Luc do you have any insight on this?
is there a way to tag someone in this forum?
The macro is not exotic and it was never a problem. The error was in using a macro without a proper include in pyindi-client.
Most of the problems with PyIndi are related to the work on the INDI Library to keep the interface in the future without rebuilding dependencies.
Also, high-level functions that facilitate the development process are implemented.
I am currently creating automatic builds for Linux / MacOS. If you like, I can add additional tests for pyindi-client.
Ok thank you for the feedback, and I apologize for mentionning the wrong problem. I was simply not able to determine what was the issue by myself.
I just realized that the macro I suspected to be the initial source of the problem was more or less an equivalent of Q_DECLARE_PRIVATE one can also find in QT source code that is apparently meant to bypass some compiler limitation with RTTI and dynamic_cast.
In my humble opinion it would be a good idea to have pyindi client tested at least as part of indi releases, as I think this project really makes indi extremely powerful, and some opensource projects with growing popularity are relying on it (hinking here at the fantastic work done by Gulinux). However it is definitely not my call, as I am not doing any significant maintenance of either indi or pyindi-client.
Thank you pawel-soja for your work on the project !
Thanks, I think I can support pyindi, monitor the status, and suggest an easier way to write in python (using INDI Library).
All upgrades are backwards compatible for C++, but I can see there are problems with swig - to be taken care of.
@pawel Thanks for helping, I really can't make new pyindi-client versions as updates are commited in the indi-core master branch. IMO this may not be the best way, as you may have to add code because of swig limitations, code that you are going to suppress on the next indi-core release as you want to keep it as simple as possiblle.
I made pyindi-client years ago, just to see if this was achievable at low cost (I remember I started with using another wrapping tool, SIP). And I was unaware that it was used in subsequent projects since then.
I've proposed to @pawel to include pyindi-client directly in indi-core. I just can't support it alone.
@dolguldur and @GuLinux Don't wait a support for npindi. Really too large.
@dedicateastro The docs for pyindi-client are the C++ docs for IndiClient. No more, no less (almost). I don't want to write a documentation on how to design an indi client.
Mmh, what do you mean by "too large"?
As I mentioned, I was thinking of either creating a new native python client, or possibly joining efforts with an existing projects. What are your thoughts on that? Is npindi too complex?
npindi is basically a python rewrite of some indi base class in addition to the indi client qt classes used in kstars. That are those "kstars" qt classes which need some work if you want to stay in sync.
With current pawel's work the indi base class may also need some rewriting. Now, as long as the INDI xml format remains unchanged, npindi should continue to work whatever implementation is used in C++.
If you only need a basic client (I suppose you only need to translate INDI messages into JSON format and send that through a webservice), you may only keep or start from the npindi base class. In your case you may even suppress the receiving thread if your client has nothing else to do. Mmmh, maybe should you also listen to your app...