D18235: Meridian flips handled by Mount

[Wolfgang Reissenberger]

wreissenberger planned changes to this revision.
wreissenberger marked 6 inline comments as done.
wreissenberger added a comment.


  Many thanks for the feedback, I will issue an update the next days.

INLINE COMMENTS

> TallFurryMan wrote in capture.cpp:3144
> OK so here, Mount is telling Capture it needs to flip, and capture either replies it is OK to flip now, or delays. Correct? So MF_REQUESTED can be set multiple times.

Correct, MF_REQUESTED is the successor state of MF_PLANNED, if Capture wants to finish a capture first. As soon as it has finished, it sends a MF_ACCEPTED answer and waits, until the meridian flip is completed.

MF_REQUESTED will be set only once, since Mount issues MF_PLANNED only once.

> TallFurryMan wrote in capture.cpp:3329
> What happens when the XML doesn't embed meridian flip information? We retain the previous state?

Here is the place where the information of an imaging sequence is copied from Capture to Mount. If the XML does not embed meridian flip information, the values on the Mount tab are not changed.

> TallFurryMan wrote in capture.cpp:4597
> We'll perhaps need a UI feedback here. No issues.

I followed the standard behaviour in the module.

> TallFurryMan wrote in mount.cpp:46
> Rationale?

The idea here is, that I start a timer with 12000ms waiting for a response to MF_PLANNED. If no MF_WAITING or MF_ACCEPTED follows within this period, a meridian flip is issued.

> TallFurryMan wrote in mount.cpp:502
> Small interval where currentTargetPosition is undefined.

Right, but only used within Mount, so I see no risk here.

> TallFurryMan wrote in mount.cpp:886
> There might be something here. If the mount parking position is misplaced, it may happen that initialHA is positive in kstars, but that the mount is still on the wrong side. Do we avoid flipping still? Arguable.

Unclear, what you mean here. Please be more specific.

> TallFurryMan wrote in mount.cpp:903
> Even if the flip checkbox is unset?

Nope, checkbox unset already covered in line 886 above.

> TallFurryMan wrote in mount.cpp:945
> We'd require error management here.

Ah, good point, I will fix it.

> TallFurryMan wrote in mount.h:59
> Aren't those name contexts clashing with Capture? It could be easy to mix them up.

Better naming idea?

REPOSITORY
  R321 KStars

REVISION DETAIL
  https://phabricator.kde.org/D18235

To: wreissenberger, mutlaqja, TallFurryMan
Cc: kde-edu, narvaez, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20190115/74cbbb86/attachment-0001.html>