But Jasem speaks from a developer's point of view. At some point, some inconsistancies may emerge, due to years of evolution step after step, that make the soft difficult to maintain and make evolve. And some choices may lead to a dead end.
So the best thing to do is to give back some logic to the whole thing by regrouping inside the same structure things that are now in separate places.
If I get what Jasem has in mind, regrouping things that have to be together under a different unique profile should simplify maintaining the separate "tabs" so when you modify something in one tab, you don't have to lose your hair because of secondary effects on other tabs
Plus, if you want to deal with parallel processing of several "optical trains", you really need to regroup things under a common flag first, before you can launch several instances of this "optical train".
So it's not about "reinventing the wheel", it's about making some place and order to allow future developments of a more stable software.
At some point, this evolution is probably necessary, even is it asks the users to leave their comfort range for a while ...
I would agree with AstroNerd's reply. Given all the other forum topics in play suggesting there are still important bugs to be worked, I believe it would be nice to hammer out the most important of those issues before looking to make a big push elsewhere. This raises a general question for me. Is there one place where the known bugs list and feature requests is maintained? I could imagine these lists having user "votes" associated to help decide how KStars/Ekos should evolve. This of course wouldn't preclude individuals from contributing for their particular interests, but it might help the more senior developers know where the biggest bang for buck resides in the user community. Finally, given the KStars/Ekos learning curve, I agree with AstroNerd's comment that achieving a robust working solution is much more fun than seeing changes made that drive a need to relearn.
Should have mentioned in my last post that the idea forwarded earlier in this thread of splitting Ekos from KStars (aka server) to handle one image train would have other good consequences. This would allow KStars to return closer to a front-end planetarium, planning, and telescope monitoring function, while allowing Ekos & Indi to coordinate remote sequence execution and device control. As has been posted previously, it would be nice to be able to plan, launch, and monitor from a laptop, but have Ekos and Indi execute on a Pi (without need to keep laptop awake). But alas, as I said in my previous post, as much as I would love to see something like this happen, I would much rather prioritize on having a completely reliable KStars/Ekos as it is currently implemented.
You do realise that by rejecting the idea of an Optical Train as a way of separating the things involved with collecting data and the things involved with positioning you are also rejecting using multiple telescopes and cameras on the same mount.
Something like what Jasem suggests wil be essential to achieve multiple telescope/camera systems. It will allow considerable simplification in how data collection and pointing are managed and synchronised. Without is a nightmare of multiple cameras, focusers, rotators, filter wheels, adaptive optics and so on. With no organisation trying to do this will dissolve into a bloated buggy mess.
Exactly how this affects the user remains to be seen. I realise that software doesn't have a good record in avoiding imposing change on users but with reasonable care any changes should be easily understood.
There's no suggestion that maintenance of the current system will be abandoned. The whole idea of a fork is to separate these experimental ideas from the main stream development.
If/when this fork sees the light of day, I'm in to test
One thing would be great : the possibility to install this evolution in parallel and with no interaction with the "historical" Kstars, so we can swap between the two of them when necessary. It's easy to change the install path to /usr/local/bin, but there is still the problem of the config files in a per user hierarchy. Though we may install the new version under a specific user of course...
but I think that two fixes will make things much easier.
One is that the INDI server is started up in the initial state, and the driver list is provided to the client software.
Another point is the addition of missing functions in each Ekos module.
Even if the driver management becomes independent in the form of a train, if the function of the Ekos module is insufficient, it will eventually have to return to the control panel and it will not be improved.
I think it's better to think in parallel with the extension of Ekos.
Regarding the control of multiple cameras, I think that either the scheduler can be made independent from Ekos and multiple control is possible, or Ekos is run independently with multiple startups.