Happy New Year everyone.
Just some thoughts from my side:
Looking at problems I've been facing with a setup that I don't think is exotic (eqmod mount driver for an EQR) where I have not been able to use polar alignment straight in the last two versions and reading some other reports down to discussions on changing the code base to a more solid handling of orchestrating events in the code I would vote to keep the focus on one platform and ensure this works solid. I really like the fully integrated philosophy of Stellarmate. On the other side I've been tempted last year to change to a Mini PC and NINA after some frustrating sessions (I have 1-2 clear nights every 1-2 month, so recording time is king).
I'm not able to support the development from my side but my take is that it would be better to focus on supporting one computing hardware and get the most out of it rather than following individual setup ideas.
Two examples that I think indicate that time is a limiting factor in the project already now:
- I used invent.kde.org/education/kstars/-/milest..._date_desc&state=all which I used in the past to check for upcoming features and if bugs I've experienced are on the list. Looking at the status for the released 3.5.6. is giving 4% complete. Either this is not the right point to go to any longer or it is not maintained.
- On docs.kde.org/trunk5/en/kstars/kstars/tool-ekos.html the Analyze tab appears not in the first overview of the user interface but just as a note very near the button even though it is of great help and underlines the strengt of an integrated system.
If I could opt I would support a 2022 dedicated to stability as Stellarmate has everything in place that would be needed to work to record images. Sure everyone has lots of ideas what else would be great, but I would rather like a realiable workhorse than a fast horse that has its character. During the recording session time that I have ideally I don't want to think about the tool I use. Stability would include support of things like 64 Bit to maybe fix the problems with large sensors (I don't have one, just follow the discussions) and the performance/stability of the WiFi or LAN connection (which is reported to be better with Astroberry on the same hardware). But I can eg, live with e.g. for performance reasons I cannot debayer on the Raspberry while imaging with my color camera , This is just a nice to have as it does not inhibit the core task of imaging.
So my two cents would be focus on a solid orchestration rather than making this a beast with all sorts of features beside the core imaging workstream and risk to frustrate users to the point they switch horses in the end. Focus the valuable time of those who can help developing this platform to focus on stability which would be for me a key criteria for attractiveness assuming the main functions are in place. Happy to support on documentation task (or even add some German documentation) to help.
Alex