Repository navigation
Fix spurious event on rangeslider.setRange with non-list value - #363
Conversation
| with qtbot.waitSignal(sld.rangeChanged): | ||
| sld.setRange(0, 255) | ||
|
|
||
| mock.assert_not_called() |
There was a problem hiding this comment.
This is the line that fails on main (it says it's called once).
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #363 +/- ##
=======================================
Coverage 84.92% 84.92%
=======================================
Files 49 49
Lines 3940 3940
=======================================
Hits 3346 3346
Misses 594 594 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
thanks @brisvag def test_range_kwarg_in_constructor(qtbot):
# PySide6 calls the python setMaximum during __init__, before `_value` is a list
qtbot.addWidget(QRangeSlider(maximum=10))can you try to normalize in if isinstance(value, (list, tuple)):
return [self._bound(v) for v in value] |
|
Like this? Why were tests not failing though? 🤔 |
yes, thanks! merging now
Because, this ultimately isn't our feature... it's an upstream feature of PySide. However, we should be testing it and we aren't. And now that I look into it more, it's actually already failing on main (relevant #300). So I shouldn't have made it sound like this PR would be the first to break it... but your last commit will prevent it from become a bug if/when we do test and support it. thanks! |
|
releasing as v0.9.1 so you can return to the upstream issue 👍 |
Spotted in napari/napari#9773.
Internally, _GenericSlider does not convert the given value to tuple/list, but converts it to list when setting
self._positionand then compares directlyself._value == self._positionin setValue:superqt/src/superqt/sliders/_generic_slider.py
Lines 119 to 120 in e636dc9
This results on an extra event fired when setting range, because it thinks that the "new" value is different from the old one.
I added a test that fails on main. I'm not sure this is the right fix, but it seems ok to me since anyways we always return
tuple(self._value)fromself.value(), so coercing shoildn't matter for the user.