A `RangeEditor` editing a `Range` trait will not use the trait's `low` and `high` settings
nicolasap-dm opened this issue · 3 comments
Using qt (pyside6 6.2.3) with the latest traitsui release (7.4.3).
A RangeEditor
that edits a Range
trait will ignore the trait's low
and high
and will default to 0.0 - 1.0 instead:
from traits.api import HasStrictTraits, Range
from traitsui.api import View, Item, RangeEditor
class FixedRange(HasStrictTraits):
a_range = Range(low=0, high=72, value=1)
def default_traits_view(self):
return View(
Item("a_range", style="custom", editor=RangeEditor(mode="slider")),
width=330, height=60,
title="Editor will not inherit low/high"
)
FixedRange().configure_traits()
(Expected: slider going from 0 to 72 instead of 0.0 to 1.0)
The same happens with other modes ("spinner").
Known workaround: assign low
and high
manually.
Limitation: this is unfeasible if the Range
trait uses extended trait names for low
and high
.
Addendum. I should also point out that if the RangeEditor
is then used, it will likely generate invalid trait values (in this case, Range
is validating to int
because high, low and value are ints; RangeEditor
however produces floats because it ignored these parameters).
It surprised me that the exception is displayed to the user with a dialog rather than with a "failed validation" color.
Digging into this a bit, if you just do Item("a_range", style="custom")
without adding a RangeEditor
things work as expected.
That's true, although this syntax would not allow selecting any other mode than the default one (here it would be "slider")
Edit: Just learned that the Range
trait also has mode
!
Key things from the looking into this:
- observed behaviour isn't a regression (which is what I was worried about)
- nevertheless it's not good
- to fix it would require a fairly substantial refactoring of the RangeEditor
- there are deeper problems with the Range trait which would likely impact a proper fix (see eg. enthought/traits#1390)
So probably not going to fix this in the near-future.