Very good point! We need to find a balance what is controlled by the Scheduler and what remains under control of other modules. We would end up in a configuration hell if we reflect all single controls of other modules in the Scheduler.
Each Ekos module should receive serialization support for its settings. ... With these serialized settings, Ekos modules should communicate with a simplified d-bus interface.
Much appreciated! The current list based view has reached its limits. With a tree based view we could show more details without losing the overview.
Supported by the settings presented in the previous section, Scheduler should improve its control facilities and provide an interface summarizing the entire configuration of the observation session. The full observation plan would be a list of target observations, themselves a list of steps to execute, embedding the serialized settings of the Ekos modules.
YES! The current approach with one master and nightly builds is great for adding small increments. But redesigns like this one simply need time to reach their maturity.
We should also discuss the possibility of integrating new features to Ekos using runtime flags. A special option pane would be used to enable or disable in-development features, in order for willing users to try them out before they are integrated to the application workflow. The new interface of Scheduler would be a good candidate, as it would force the development to proceed in non-breaking iterations.