D18235: Meridian flips handled by Mount

Wolfgang Reissenberger noreply at phabricator.kde.org
Wed Jan 16 10:38:02 GMT 2019


wreissenberger marked 8 inline comments as done.
wreissenberger added inline comments.

INLINE COMMENTS

> TallFurryMan wrote in mount.cpp:46
> My question would be better formulated as "why specifically 12 seconds?".
> I understand it is arbitrary, but it should perhaps be related to a timer value in Capture as primary module that could be annoyed?
> Or maybe a simple TODO asking for a customizable delay in the Ekos options?

Ah, damn, I meant two minutes. Currently, I would not put it into the Ekos options but first gain some experience if this feature really makes sense at all.

> TallFurryMan wrote in mount.cpp:502
> I disagree: this is the source for the d-bus property currentTarget, and as such you don't control when it can be accessed.
> Could this be an object instead of a pointer? So that it may be uninitialized or plain wrong, but never undefined?

Yes and no. I made currentTarget accessible as a first step when shifting the meridian flip to Mount. Currently, there is one access in Capture when checking, whether the slew has begun (line 4201).

So currently, there is no risk that we step into it in an undefined moment.

I want to remove the external access to currentTarget anyway, since with the new design the mount controls the meridian flip and communicates the state through events.

But nevertheless, good point, I will work on removing the external access to avoid the weakness.

> TallFurryMan wrote in mount.h:59
> Well, the same MF_ prefix makes Mount::MeridianFlipStatus and Capture::MFStage similar.
> Both are public declarations, and both are enums, so there could be a way to use one instead of the other by mistake.
> Tentative: FLIP_IDLE, FLIP_PLANNED, FLIP_WAITING... like the parking status. The MF in Capture is probably similar to the others.

Good idea, that's easy to be changed.

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/20190116/28a30580/attachment.html>


More information about the kde-edu mailing list