Implement customizable dusk and dawn offsets.
ClosedPublic

Authored by TallFurryMan on Sep 11 2019, 9:05 AM.

Details

Summary

Customizable dusk and dawn offsets introduce two new Ekos options, located in the Scheduler option pane.
Dusk (resp. dawn) offset will apply a positive or negative hour offset to today's astronomical dusk (resp. dawn) when scheduling observation jobs.
The dawn offset and the pre-dawn offset are cumulative, but the dawn offset allows an earlier or later dawn to be used both while scheduling and executing.

The resulting dusk-to-dawn interval is displayed in the Scheduler UI on the right side of the Twilight checkbox.
If the Twilight restriction is checked, the modified dusk and dawn values will be used to schedule the observation job to night time.
If the Twilight restriction is not checked, the observation job will not depend on night time and the modified dusk and dawn will be ineffective in scheduling that job.

The dusk and dawn offsets can be modified from the Ekos Scheduler options, and the night time interval displayed in the Scheduler UI will be updated when applying the changes in that dialog.

Additionally, if the Scheduler is not running, jobs will be re-evaluated to take the new dusk and dawn values into account.
However, jobs will only effectively update their schedule if the night time constrain them to do so, not if the night time restriction relaxes.

Notes:

  • This differential relocates and resizes some UI gadgets to slightly improve the presentation.
  • UI is rehauled to resize properly, but no further attempt is made to enhance it (well, it's a rehaul though). Especially, tab order is still broken.
  • Night interval is displayed in 24-hour format, it is not straightforward to display locale-compliant hour/minute strings with Qt.
Test Plan

Checking the night interval UI:

  • Open Ekos, switch to the Scheduler pane.
  • Locate the night interval on the right side of the Twilight Restriction checkbox.
  • Open Ekos options, switch to the Scheduler pane.
  • Locate the dusk and dawn offset editboxes.
  • Update the values, check that applying option changes updates the night interval on the Scheduler UI (use Apply and OK buttons).
  • Update the values, check that dismissing option changes without applying retain the night interval that was set previously.

Checking the job schedule update:

  • Add an ASAP observation job that is schedulable today at dusk, with Twilight Restriction enforced.
  • Check that the job is scheduled inside the night interval displayed in the UI.
  • Restrict the night time to a smaller interval using the dusk offset in the Ekos Scheduler options, and apply changes.
  • Verify that the job is properly re-scheduled inside the night interval.
  • Relax the night time to a larger interval using the dusk offset in the Ekos Scheduler options, and apply changes.
  • Verify that the job is not re-scheduled, and retain its startup time.
  • Manually refresh the job schedule, verify that the job is re-scheduled at the updated dusk.
  • Execute the same steps with the Scheduler running, verify the Scheduler falls asleep waiting for the observation job, and that the schedule is retained.
  • Verify that the job is not rescheduled until it is supposed to start:
  • If the job is restricted to start later, it is effectively re-scheduled to a later date.
  • If the job is relaxed to start earlier, it is effectively starting at the present time, and not re-scheduled to start earlier on a later day.

Diff Detail

Repository
R321 KStars
Branch
improve__dawn_dusk_offset (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 16755
Build 16773: arc lint + arc unit
TallFurryMan created this revision.Sep 11 2019, 9:05 AM
Restricted Application added a project: KDE Edu. · View Herald TranscriptSep 11 2019, 9:05 AM
Restricted Application added a subscriber: kde-edu. · View Herald Transcript
TallFurryMan requested review of this revision.Sep 11 2019, 9:05 AM
wreissenberger accepted this revision.Sep 11 2019, 1:31 PM

Very nice idea, Eric - well done!

This revision is now accepted and ready to land.Sep 11 2019, 1:31 PM
alexcherney accepted this revision.Sep 11 2019, 2:41 PM

great idea indeed. I look forward to using it

mutlaqja requested changes to this revision.Sep 12 2019, 6:38 AM

why is applyConfig() needed?

kstars/ekos/scheduler/scheduler.ui
9–10

Must be less than 800 pixels.

This revision now requires changes to proceed.Sep 12 2019, 6:38 AM

We need applyConfig to trigger updates in modules following a change of settings. For instance, altering lead time in the options requires a re-evaluation of the schedule. Granted, there are not so many cases for now because most procedures use options when they execute, without preview. Scheduler prepares execution and present it to the end-user for verification as a job list. Thus while the evaluation would be done again when starting the observation, and options taken into account at that moment, scheduler needs to update its presentation when options are applied to retain coherence.

kstars/ekos/scheduler/scheduler.ui
9–10

See my comment on D23892 on why we don't care actually.

Regarding the 800 pixels, it actually affects it and by default now we end up with more width that cannot be reduced.

For the applyConfig, maybe use this in scheduler?

m_ConfigDialog = KConfigDialog::exists("settings");
connect(m_ConfigDialog, &KConfigDialog::settingsChange, this, &Scheduler::applyConfig) ; ?

Ah you mean there is a missing restriction in the manager? I'll double check ok. Thanks for the connection example, I'll try to use that!

TallFurryMan planned changes to this revision.Sep 12 2019, 12:33 PM

Manager dimensions restricted to 796x568, to leave room for window manager decoration and remain under 800x600.
Rehauled the Scheduler UI completely, removed ALL size specificities, and had the layout manager do its job on its own for the entire UI.
Qt layouts are nice, but one need to trust logic and hierarchy, not Qt Designer views.

Also slightly changed the Option dialog creation so that the dialog is effectively prepared before modules connect signals to it.

Dawn and dusk offsets tested over two nights, work as expected (this change is actually far simpler than the UI stuff...).

Oh, and I removed years from dates to compact the view even more.

TallFurryMan edited the summary of this revision. (Show Details)Sep 18 2019, 8:37 PM

Ok, how about KConfigDialog ?

TallFurryMan added inline comments.Sep 18 2019, 10:10 PM
kstars/kstarsactions.cpp
1018

KConfigDialog management is here. I call prepareOps() when initializing actions in the KStars class, and this pre-creates the dialog.
The only change that produces is that the dialog is in cache before actually opening the dialog.

mutlaqja accepted this revision.Sep 19 2019, 5:03 AM
This revision is now accepted and ready to land.Sep 19 2019, 5:03 AM
This revision was automatically updated to reflect the committed changes.
mutlaqja reopened this revision.Sep 19 2019, 5:21 AM

Ok, so the Ekos UI now becomes squishy. Check attachment.

This revision is now accepted and ready to land.Sep 19 2019, 5:21 AM

I didn't touch the manager, except for adding the dimension you mentioned and that was not there in the first place. As you can see, the manager is unable to achieve 800x600 without overlapping gadgets as it is now. I made sure Scheduler was not preventing the dimension from being reduced to the required size. The manager issue must be tackled by another diff.

By the way, the overlap is quite neat I think. But I agree there is much space wasted on this page.

it's not 800x600, it's always been 800x800

Oh no. You mean I've been tweaking the UI to death just because I thought you meant 800x600 and not 800x800? That's embarrassing for the hairs I've been pulling out for that diff...
Could you simply tweak as an additional differential the minimum size block at the very beginning of manager.ui to relax my restriction to 768 instead of 568?

mutlaqja closed this revision.Sep 23 2019, 7:55 AM