Currently, the scheduler is a class with more than 7200 lines of code which makes it very tricky to maintain. This approach follows the idea shift job specific scorings from Scheduler to SchedulerJob:
This is an alternative (simpler) approach to D20001.
Well, this is the downside of this refactoring effort. Since the Scheduler is awfully complex and intertwined, it needs to be tested carefully.
At least from the intention, the execution of scheduler jobs should not be touched, only the correct calculations of scores. So please test all combinations that have effect to the score of a scheduler job.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
I cannot disagree with this, this is what you proposed last year, and this is the approach I support!
Obviously we need to be very careful to not moving the complexity from one class to the other.
| kstars/ekos/scheduler/schedulerjob.h | ||
|---|---|---|
| 27 | Huh, what was that "default" I didn't know about? C++11 specificities? | |
| 504 | Perhaps make it static? | |
I propose we then divide SchedulerJob into SchedulerJobModel and SchedulerJob, deriving from SchedulerJobModel.
We can then move all the accessor stuff away into SchedulerJobModel, and focus on making SchedulerJob more a controller.
We should be able to tweak SchedulerJobModel to comply with the QT model interface perhaps.
| kstars/ekos/scheduler/schedulerjob.h | ||
|---|---|---|
| 27 | Well OK that's a C++11 keyword stating that the implementation was to use the default C++ constructor. Agreed as you provided one. | |
I think we should merge this. I'll then separate scheduler.cpp into several file to try to clarify what functions are for. I'll also separate the interface from the implementation, so we don't have too many private stuff cluttering.