- Demonstrate some fancier use cases that Traits UI does not handle well, like double-ended sliders made in Chaco (with histogram of a dataset being shown underneath).
- Bikeshed all the names.
Develop a reasonable story for the reverse wrapping: wrapping Traits object in the Qt item models API. Traits UI’s
TabularAdapteris a reasonable start, but it misses a lot of opportunities to be ideal according to our Core Principles.
Have sufficient replacements for all common Traits UI editors and the ways that we have hacked them. The following are those that are sufficiently complicated that a configured raw widget
Binderwould not suffice (or are not otherwise covered elsewhere here).
TextEditor: we still need a
LineEditcustomization that converts specific Python objects (floats, ints, whatevers) to/from strings and validates the same.
EnumEditor: there are two distinct use cases, to select from a list of specific items or to allow write-in values with some recommended choices. Keep those use cases separate.
BoundsEditor: don’t reuse the implementation. Use
(low, high)tuples for both the value and the outer range. It’s easier to handle the events that way. Also, we want to be able to grab the middle of the slider to move the whole range and not just each end independently. Keep it interface-compatible with the Chaco double-ended slider.
ColorEditor: design a nicer UI than the current one.
As you can see, it’s not that much.
Wrap QtQuick components. QML is going to be particularly good for heavily customized table widgets.
- Other toolkits.
- Constraint-based layout. It can be useful for some advanced use cases, but is
largely unnecessary for almost all of our use cases. It can be hard to debug
without the right tooling (a la Apple), and the simple use cases sometimes
fail inscrutably. Of course, it can be added independently as a