Guider binning

[Jasem Mutlaq]

So I think we could still retain the current Options:: approach for all
modules, but for some values, we tie them to each equipment profile if
there are changes made?

For example, the select for the last used camera, or last used filter
wheel...etc. We would have to make a specific list to find which settings
are tied to a profile vs generic options.
--
Best Regards,
Jasem Mutlaq



On Thu, Jun 4, 2020 at 3:04 PM Eric Dejouhanet <eric.dejouhanet at gmail.com>
wrote:

> Hello Jasem,
>
> You raise an interesting point. Originally, I hadn't planned to do
> anything different than what the Options are doing now. That is, only
> offer the possibility to serialize the set of Options pertaining to a
> specific Module.
>
> Then, from Scheduler, I would send those serialized settings (if any) to
> each module when initiating an Observation Step that involves them.
> Thus, because Scheduler is supposedly using a specific equipment Profile
> (which it actually may do only once at the beginning I think), we can
> say that the listed settings are tied to an equipment Profile. At least
> that was my intent, from the point of view of Scheduler.
>
> Now, if I consider the point of view of the module alone, the user may
> choose to load Settings created with a different set of devices than
> what the current Profile is defined with. That currently happens in the
> Capture module, where one may create a Sequence file with the CCD and
> Filter Wheel Simulators, and load it with their real camera and filter
> wheel (which their Simulator is mimicking). There are sometimes
> incompatibilities, and the code currently does not handle that very
> well. We can expect the same situation to happen in other modules.
>
> There is some sort of fallback method to design here in each module
> separately. Not the right camera device? We may just reject the
> settings, or pick the device currently in use and hope for the best, or
> default some fields, or define a blank "default" value that would reset
> a parameter to its default. Any ideas?
>
> --
> -Eric
>
> mailto:eric.dejouhanet at gmail.com -- https://astronomy.dejouha.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20200604/19998111/attachment.htm>