Hello Jasem, could you test this and tell me if it fits the original attempt in the user interface? I'm trying to make the scheduler tab and capture tab behave a bit similar, but perhaps that's not where the author wanted to go? Besides, it fixes the issue raised by pcxz on the forum.

Hi Eric, it looks fine and it is a good think to have a consistent experience. I noticed something I haven't noticed before which is the job evaluation now runs as soon as your add the job? is this intentional? what's the rational?

Thanks. Yes, the immediate evaluation is wanted. The rationale is that the scheduler should be consistent, and should not display both non-evaluated and evaluated jobs as there is no way to differentiate them in the table. All jobs evaluate when the scheduler starts, so having some not evaluated when the user clicks the start button is a usability problem somehow. For instance, if a job is already complete with all captures stored, or if a job cannot schedule because of altitude, it's better to tell the user before starting.

Extending on this, I want to evaluate all jobs periodically, so that the scheduler can't start with asap jobs that are already in the past. Currently the scheduler reorders those afterwards without problem, but it causes an unexpected change to the visible schedule and we don't want to surprise the user. Also, duration estimates are incorrect currently, and are causing reorders too when the real duration is larger than 5min and aborts the next jobs. I'll move the estimates for each step at a location the user can update (or possibly make the scheduler measure and learn that duration).

I rebased this differential over D13388.
There is still an issue when re-scheduling jobs starting at the same time, visible when using the Mosaic Tool. But that's minor, I'll fix this in a later commit.