Allow entering larger values in sliders and spinboxes than current min-max

[AnaVukasinovic]

This bugfix allows the sliders and spinboxes in Layer Details, including the RGB sliders, to no longer have fixed minimum and maximum values. Users can now input arbitrary values into the spinbox or edit box. If the entered value exceeds the current maximum or is below the current minimum, the limits are updated accordingly, and the sliders adjust to reflect the new range.

Closes #394

[RudiLauster]

Hello Andrea @ameraner ,

so I have checked this PR and I think it is ready to be handed over to you 🙂

I would like to remove the "DRAFT" label but I lack the rights and Ana is not available today. Maybe you could do that?

Previously the Coverall failed again since the code updated is QT widget code which has not been provided with unit tests beforehand. And since we mostly do not have tests for GUI logic from what I see (e.g. _test_rgb_config is disabled) I added
"# pragma: no cover" to the methods updated.

Is that ok with you?

[ameraner]

Hi @RudiLauster and @AnaVukasinovic , thank you for this!
I just tested the branch and it seems to have a problem: now, when I try to enter a new value in the Layer Details spinbox, right after I type the first number, without any other input the value is accepted and the focus/curser jumps to the next field (e.g. gamma when I try to modify the max value).
The logs say e.g. this, when I try to set the maximum to 360 - it takes the 3 as first input and accepts it right away, no possibility to enter the full number

# I reset to default
2025-05-06 12:53:15 DEBUG scene_graph:change_dataset_nodes_color_limits:L725 changing 6ae8ece4-2a78-11f0-b5c9-005056b381f1 to color limits (164.14999999999998, 328.15)
# I try to type 360 but only 3 is accepted and SIFT moves on
2025-05-06 12:53:27 DEBUG layer_details:_spin_box_changed:L374 spin box 6cf2b920-2a78-11f0-bdb1-005056b381f1 max => 3.000000 => 3.000000
2025-05-06 12:53:27 DEBUG scene_graph:change_dataset_nodes_color_limits:L725 changing 6ae8ece4-2a78-11f0-b5c9-005056b381f1 to color limits (164.14999999999998, 3.0)

maybe it's a OS specific behaviour? I'm testing it on linux... Could you please take a look what could be the issue?

[ameraner]

Regarding the tests: I deactivated them temporarily in #437 and want to reactivate them asap in #439 - I did this since due to an unknown issue they were failing in the CI (but not locally), so in order to be able to run the tests on our new PRs successfully in the CI I turned them off temporarily.
So please could you still put some new relevant tests in e.g. tests/view/_test_rgb_config.py? You can also remove the # pragma: no cover, and we can still accept the PR knowing that the tests are artificially deactivated, but have been added and pass locally. Sorry for this, but it was the most pragmatic way forward at the time...

[RudiLauster]

Hello Andrea @ameraner,
so, we found the cause of the focus jump. It was a consequence of the necessary workaround that resolves this black-magic double invoke issue when clicking inc/dec at the max/min limits.
For that purpose we introduced a custom spin box class QAdaptiveDoubleSpinBox. The name is a bit misleading in this context, but actually for issue #369 "Smaller increment for arrows controlling color limits ..." we need this class and there it is fully dressed to realise the desired functionality.

So, for testing the QT-test issue I enabled the test_rgb_config to see what goes wrong. As discussed this test would serve to cover the changes applied for rgb_config.

[RudiLauster]

Hi Andrea @ameraner
So, coveralls is happy now since I could reactivate the test for rgb_config which was updated. Do you think we can do without creating a new unit test for layer_details?

[ameraner]

Merged as part of #452