[WIP] Feature/advanced tuple editor

[itziakos]

This PR augments the TupleEditor to support extra validation provided by the user in the Editor factory or defined in the trait (see ValidatedTuple PR #enthought/traits#205).

example:

>>> from traits.api import Int, HasStrictTraits, Tuple
>>> from traitsui.api import View, Item, TupleEditor
>>> class Model(HasStrictTraits):
...     value_range = Tuple(Int(0), Int(1))
...     view = View(Item('value_range', editor=TupleEditor(fvalidate=lambda x: x[0] < x[1])))
... 
>>> model = Model()
>>> model.configure_traits()
>>> 

normal values

invalid field

invalid tuple (x[0] > x[1])

note: Tests require #enthought/traits#205

[jonathanrocher]

This is cool, especially your context manager to dispose the ui after x sec. Don't forget a contribution to CHANGES.txt

[corranwebster]

I think this probably needs to wait for a traits release containing the ValidatedTuple before its safe to merge this.

[itziakos]

@corranwebster this is now ready to review

[codecov-io]

Current coverage is 53.32%

Merging #182 into master will increase coverage by 1.72%

@@             master       #182   diff @@
==========================================
  Files           115        111     -4   
  Lines         11401      11090   -311   
  Methods           0          0          
  Messages          0          0          
  Branches       1868       1784    -84   
==========================================
+ Hits           5883       5913    +30   
+ Misses         4994       4696   -298   
+ Partials        524        481    -43   

Powered by Codecov. Last updated by 536ff2c...ef2a78d

[mdickinson]

I wonder whether both fields should have a red background in the case that the pair of values fails validation. It's not obvious right now why one field is red but the other not. With the example from the initial comment (and validation replaced by fvalidate), I can achieve all three of the following states (the first text box is active in all three cases).

[corranwebster]

This should be the other way around (unless you have a particular use-case in mind). Because one HasTraits class can potentially have many different views, you generally want thing specified in the editor to override things specified in traits.

Although not exactly analogous, compare with (note that the label in the Item wins):

from traits.api import HasTraits, Float
from traitsui.api import View, Item


class Test(HasTraits):

    x = Float(label='Variable x')

    view = View(Item('x', label='Var x'))

t = Test()
t.edit_traits()

[itziakos]

As you say it is not analogous. Since there is no restriction on the label. For example if the Editor validation overrides the trait validation it can potentially result in an invalid value been forced into a trait which will throw an exception.

[itziakos]

Thinking about it a little more, maybe a compromise would be the union of the trait validation and editor validation.

At the end the problem is about who is responsible for ultimate constrains in the values (not the representation) the traits model or the traits ui view

[corranwebster]

A more powerful way of validating is to have the validator have a chance to modify the values to something that might work (see the way that Traits validators work). So something like:

try:
    editor.value = self.fvalidate(new_value)
except TraitError:  # or something else appropriate
    for i in range(self.fields):
        setattr(self, 'invalid{0}'.format(i), False)

[itziakos]

I am not convinced. If you want the validation to change the value then use a custom trait that preforms the coersion. Normal traits like Float, Range and Int do not covert the values. A number of editors already provide a format function to support conversions.

[itziakos]

Also the fact that the validate function of some traits changes the actual value is an internal implementation/optimization. For example the coercing traits CFloat and other will do the validation at the same time as coercion. So by returning the coerced value one does not have to perform the coercion again. But this does not happen in all the traits just those that their Name/Definition imply a coercion.

The generic trait behavior e.g. a Property has separate functions for get, set and validation. Where conversion does not have to happen in validation but in set

[corranwebster]

Any reason why fvalidate instead of just validate or validator?

[itziakos]

It has been a while... So initially I had it as validator but then I changed it to fvalidate to be similar to the Property fget, fset, fvalidate

[corranwebster]

I am tempted to merge this as-is. Nothing above is a show-stopper, and it would be good to have this finished.

[itziakos]

@corranwebster, this PR still needs so fixes related to the ui behavior.