3.6.1 testing bugs

[Hy Murveit]

I created https://invent.kde.org/education/kstars/-/issues/217 with the
list of all issues I saw last night.

On Sat, Sep 17, 2022 at 3:01 AM Jasem Mutlaq <mutlaqja at ikarustech.com>
wrote:

> Regarding options, there has been some changes in this version to support
> Global and Per-Train settings.
>
> For any item like the kstars.kcfg file that has a corresponding GUI item
> not handled by KConfig, it should be handled as follows. The GUI item is
> named exactly like the field name in kstars.kcfg but with the first letter
> always being lower case.
>
> This way, we can call Options::self()->setProperty(name, value)
>
> For example, the reason the refresh algorithm was not saved was because
> the first letter was not lower case (I just corrected that). So in
> kstars.kcfg it is: PAHRefreshAlgorithm while in the GUI it should be
> pAHRefreshAlgorithm
>
> Why is this useful? Two folds:
>
> 1. All global settings are now *automatically* saved. No need to
> explicitly call Options::setFOO(....). The only reason we need to call
> Options::setFOO directly is for the non-GUI options (for example, those
> handled by KConfig or non-GUI at all).
> 2. All per-train settings are also automatically saved. You changed the
> refresh algorithm while using the Primary train? Now Primary train will
> *remember* this setting in addition to the setting saved in the *global*
> settings. Now if you switch to Secondary train, the same option is kept as
> is. But if you explicitly change the setting while in the secondary train,
> then IT IS saved for this particular train.
>
> This immediately resolves all the settings woes we had in the previous
> versions. Everything automatically saves thanks with Q_PROPERTY and
> KConfigSkeleton support for this. I've wanted to do this for a long time
> but there was an architecture limitation that stopped me from adopting this
> earlier. The biggest limitation we have now is that it doesn't work on
> 32bit systems. The only 32bit system is armhf (I don't think anyone uses
> x86-32 nowadays), but I think it's time to move on now that arm64 is truly
> mainstream.
>
> --
> Best Regards,
> Jasem Mutlaq
>
>
>
> On Sat, Sep 17, 2022 at 12:52 PM Jasem Mutlaq <mutlaqja at ikarustech.com>
> wrote:
>
>> Hello Hy,
>>
>> Thank you for the report. Can you please add it (in one issue) to here?
>> https://invent.kde.org/education/kstars/-/issues
>>
>> Would be better to track them there.
>>
>> --
>> Best Regards,
>> Jasem Mutlaq
>>
>>
>>
>> On Sat, Sep 17, 2022 at 8:18 AM Hy Murveit <murveit at gmail.com> wrote:
>>
>>> I'm testing with HEAD plus MR
>>> https://invent.kde.org/education/kstars/-/merge_requests/742 (which
>>> should only affect Dark Guiding).
>>>
>>> 1) Guiding with scheduler gets suspended right away and never restarts.
>>> I've tracked that issue down to this line,
>>> https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/capture/capture.cpp#L6060 but
>>> that line makes sure the exposure isn't a Light frame, and yet all I'm
>>> capturing are Light frames. Perhaps the getFrameType() is not set up yet? I
>>> commented out those lines, restarted, and guiding no longer gets suspended.
>>> I am leaving finding the underlying issue to you folks. This is a
>>> show-stopper for internal guiding.
>>>
>>> 2) My guiding exposure gets reset to 1s on restart, even though I've set
>>> 5s several times. I can check again, but it has happened several times.
>>> Doesn't consistently happen, though.
>>>
>>> 3)  Polar alignment in refresh mode with the plate-solve scheme never
>>> refreshes.  The move-star scheme works. *I discovered that the refresh
>>> algorithm-choice parameter is not being set anywhere. It can't have always
>>> been this way...in any event, I've written *
>>> https://invent.kde.org/education/kstars/-/merge_requests/743* to fix
>>> it. Seems to work now in the simulator.*
>>>
>>> 4) When I first started, all tabs had many things disabled. I needed to
>>> change trains, then change them back to get things working. After that, on
>>> restarts, things worked. I'm guessing there's a stored parameter that isn't
>>> initialized at first. This happened on the simulator too. Leaving for you
>>> folks to debug.
>>>
>>> 5) I suspect the guide tab is defaulting to the Primary train (it should
>>> default to Secondary).
>>>
>>> With the fixes MR 742 and the lines commented out as described in #1
>>> above, I am currently successfully running a scheduler job. It has
>>> autofocused, aligned, guided with dithering, dark guiding, ...
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20220917/d5563e51/attachment.htm>