- User Since
- Apr 13 2018, 9:37 PM (44 w, 4 d)
Sat, Feb 2
Congratulations to all of you, this really is an improvement to the platform.
Thu, Jan 31
D18627 requires attention. Is it compatible/complementary/unnecessary with this diff?
Fri, Jan 25
Thu, Jan 24
Cristal clear, thanks.
Wed, Jan 23
There's something I'd like clarified.
First, if the mount is set east of the meridian at an original position, and is not tracking, and we wait long enough that if it was tracking, it would flip. What happens if we then start tracking from that eastern position? Do we get an unneeded and ineffective flip request?
Second, if a capture overlaps the meridian flip, I don't readily understand whether the capture is aborted, the flip executed, and the capture restarted, or if the capture continues and delays the flip, potentially for very long. This situation could be pre-planned by Scheduler.
I'm sorry, I couldn't test all this. But this seems really good.
Jan 16 2019
Jan 14 2019
That's great, agreed. I added a few (as usual) pedantic comments. My setup is out of order while I install the fixed obs, so I don't know when I will be able to test.
Jan 7 2019
Dec 28 2018
Dec 19 2018
Dec 7 2018
- Minor grammar typo.
- Fix regression on current job status.
Dec 3 2018
Dec 2 2018
Complete list of changes. Job selection highlight is now under control.
Nov 28 2018
OK the index concept of currentRow and the index concept of selectRow are different. I will move to a custom QModelIndex as soon as possible.
@wreissenberger Thanks your patch! I observed that when sorting jobs per altitude manually and sorting is not expected to change the order, the selection moves up by itself one row at a time. I'll check this.
Nov 26 2018
In the case of floating point, either QString("%L1").arg() or ki18n().subs() should be used, and HFR is a float (no i18n with args here).
But I didn't investigate whether, while the QString method systematically used the system locale, the ki18n could handle a locale switch in the application without system locale changes.
You should use QString("%L1").arg(variable, width, 'f', précision) to properly format floating point values using the decimal point of the locale
Nov 22 2018
OK that's clear :) thanks for taking the time to check this!
Go ahead and post, I can integrate it to this differential.
Nov 21 2018
Nov 20 2018
Issue found: when changing the start-up constraint from asap to culmination time, and there are two jobs in the list, the second job is overwritten with the first job contents.
Investigation in progress to determine the root cause.
Nov 18 2018
Nov 17 2018
This went out of my list, I'll check this. I think the main point - the dome - was merged.
Nov 15 2018
Progressing on use cases at https://github.com/TallFurryMan/kstars/wiki.
Nov 12 2018
Nov 10 2018
Differential changes are now complete.
Please start testing now while I write the changeset documentation and describe integration tests!
Nov 9 2018
Still WIP, not entirely rebased, but shows were the rewrite is at.
UI is probably prettier than it was before, but that won't help the first Ekos tab.
Altitude sorting is clarified with the UI rework, but clicking the sort button is not stable.
Row selection is still to be fixed.
All schedule consolidation issues are now fixed!
I'm nearly finished, still quite a bit of testing needed.
Nov 3 2018
Still WIP, need to rebase, fix a few logs and add altitude as a column.
- Rewrote algorithm documentation.
- Fixes from Phabricator comments.
Nov 2 2018
This is still a WIP. Posting advancements to share progress.
Oct 28 2018
I also plan to add altitude for startup time, with an icon showing whether the target is rising or setting.
This weekend I found out that most calculations in the scheduler were using the current date instead of the job date (which could be the next day, thus offset with ~15min), and that sometimes local to universal conversions were using the time zone of the system running KStars, instead of the geographic location of the observatory. But trying for instance to calculate the culmination of a target at a future date is somewhat tricky with the current code.
Thanks for this report!
- Yes, agreed, the way the QWidgetTable works for selection is implemented and documented in such a contrived way that it appears to be bugged. SelectRow() should be used, but never results in the right effect. There are apparently several follow-up signals that make a mess with the rendering...
- I agree also there, the behavior of the sort option is opaque. Well, for the altitude at least. It works well only when the targets are all asap, and all rising. I plan to change the order predicate so that prioritary targets are the one setting, not the highest ones. Moreover, there's no point in sorting both in priority and altitude probably. Except for infinitely looping jobs, priority is a weird feature now...
Oct 25 2018
Oct 13 2018
Regression fixed in D16173.
Oct 12 2018
I can't believe it: the side-effect is in D14665... Back to August 7th... I'll issue a fix.
D15937Sorry! Finally got it. I tried to guess what would be your configuration, and found the relation with "Sort Jobs by Altitude and Priority".
This is a regression to D15937 indeed, unrelated to D16151.
So that's certainly a regression on D15937. I remember testing with full schedules, but not trying to modify one. I'll double check, thanks.
Huh? I didn't expect this report :) you mean you can't delete scheduler jobs, or sequence jobs?
Differential is renewed as D16151, let's continue discussing there.
Oct 11 2018
Having a visible option is not that good for user experience, I'll settle for the warning only.
For sure. Right now both Scheduler and Capture source codes are very hard to read, and it's possible that many contributions aren't concluding into pull requests because of that. Any attempt at cleanup should base on such a list of use cases. How could we involve the community on this?
Jasem I also need to remove your (early) optimization which is not re-loading the sequence when looping a schedule job, as counts have to be reset by the Scheduler if the end-user manipulated the storage. Also if for some reason a repeating job was interrupted and is restarting anew, we need to send again the sequence.
I tested a few use cases, and I couldn't find a situation where I myself would benefit from that option. So I added a warning in the bottom console when such reset happens. Will push soon.
Oct 10 2018
Thanks for these comments!
A few notes for clarity, and for you to shout if you disagree in advance:
I was about to push the missing history, but I'm delaying as I found an issue with the way the completed frame count is set when ignoreJobProgress is not set.
The count is taken to be sequenceID minus one, but that can't be correct if there are missing files in the series on disk.
I'll disconnect this relation, Capture should do what it is told to by the configured sequence, or rely on what required count the Scheduler is providing.
Yes, when jobs are not sorted per priority/altitude, re-evaluating is necessary each time a job is moved. When that option is enabled, you can't move jobs anymore. I will push an additional differential to actually sort the visible list automatically when "Sort jobs by Altitude and Priority" is enabled for better user feedback.
Could someone test and merge this one? Or does it have issues applying?
Oct 9 2018
Indeed I missed many things here. Sorry for pushing something so incorrect...
Oct 8 2018
I did a quick test, and it appears the dome simulator is already unparked when starting. I'll fix the park/unpark request in the same way as the mount. I'll also check the dustcap.
Oct 4 2018
The property should match the content of the XMLs in the root folder. I can see there is a property named parkStatus and a signal named newParkStatus for those devices. I haven't yet returned to that diff, sorry.
I also plan to reorder the jobs automatically directly in the queue table when "Sort jobs by Altitude and Priority" is enabled, to provide a clearer feedback to the end-user.
Rewrote cast to double with static_cast.
Oct 3 2018
Ah ! Interesting ! Thanks!
It seems I accepted my own change, but I have no idea how I did that. It was a bit late, sorry.
This morning I finished verifying all test vectors, so this differential is ready from my point of view and I will base further changes on it.
This differential might not be a bit rough in two cases: approaching twilight, and approaching altitude limit. Those issues are next on my list.
OK it might be that the property parkStatus is not converted properly. It is working for the mount interface, so I think it should be easy to spot differences there.
Oct 2 2018
I assume you have a Dome in your profile. I also assume that you have the syntax error fix in your tree (it is in this differential, but Jasem did also merge the fix in parallel before the final version of this fix), so hopefully there is no further syntax error introduced? Indi state 4 is INDI_PROPERTY_CHECK, so your setup is hung waiting for one of these four things to come up: dome, mount, dustcap or capture interface. There are logs for each of these, added by this differential. Which ones do you see?
Reworked differential to fix schedule of jobs.
Sep 30 2018
OK. Should I drop the rest of the differential?
Sep 29 2018
I'm working on the job termination issue. Will fix all of them at once. I'll first debug the cmake stuff with the moc generation, perhaps we could remove the XMLs in the source and install the generated XML interfaces instead. If that's already the case, I'll just drop the source XMLs.
My problem is that I can't seem to regenerate mocs properly. The XML used by the mocs are generated on-the-fly, supposedly from the class header and not from the source XML, but while dustcap, mount and other interfaces create the ready() signal flawlessly, the dome interface will just not get it through. And I don't know why yet, which is irritating...
Mmmh, dome recovery is not working entirely yet. But this is a first step. It can be merged, or I can push an update if I find the time to fix.
Sep 28 2018
Sep 27 2018
OK, so properties are straightened up (not all of them) and I understand better the design.
I'm working on the issue that if the mount/dome/dustcap park/unpark is not checked, properties don't come up.
If scheduler is stopped, then those boxes are checked, then scheduler is restarted, scheduler hangs waiting for either one.
Mitigation is possible, but stopEkos does not reset its state properly, and cannot recover.
Probably a regression. I'm about to break through on this.
Sep 18 2018
On hold until I really understand how QT_PROPERTY works.
Modifying the interface xml apparently has no impact on the resulting executable, and thus my test is not effective on dome's isMoving.
It just happens that the value returned by the QVariant conversion is false, and no actual communication with the mount interface is taking place through the properties!
Sep 17 2018
Rebased, and adjusted float format for coherence.