<table><tr><td style="">wreissenberger added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D25380">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Yes, I agree. But this is just another sanity check. i.e. if the mount is slewing after settling time timeout, then something is very wrong and the state changes to ALIGN_SLEWING... after which is will actually end up calling settling again.</p></blockquote>

<p>Sorry for being stubborn, but I don't see how this could happen. If the mount changes from tracking to slewing before we reach the end of the settling time, it should have been already detected by processNumber() or processSwitch().</p>

<p>I could add this sanity check here, but I do not see a way how I could test it. Maybe with a polling interval significantly longer than settling time, but it still might happen that processNumber() steps in first.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R321 KStars</div></div></div><br /><div><strong>BRANCH</strong><div><div>align_startrails</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D25380">https://phabricator.kde.org/D25380</a></div></div><br /><div><strong>To: </strong>wreissenberger, mutlaqja, lancaster, TallFurryMan<br /><strong>Cc: </strong>kde-edu, narvaez, apol<br /></div>