Non-hacky solution for runtime created traits can't be displayed in View

Question

Repeatedly I find myself in this situation,

class MainDisplay(HasTraits):
    a=Instance(A,())    
    def __init__(self):
        self.a=A()
    traits_view=View(...)

class A(HasTraits):
    i=Int()
    j=Int()
    k=Int()
    def __init__(self):
        i,j,k=something
    a_display=Group('i','j','k')

Problem: I want to display a.i,a.j,a.k in my main display.

Constraints:

(1) i,j,k absolutely must remain members of A and not MainDisplay. It just makes no sense to include them in MainDisplay and if I did that for every trait, MainDisplay would become far too cluttered.

(2) MainDisplay must not inherit class A. If it did, I could do "Include('a_display')" within traits_view. This is a nice trick for compartmentalizing some of the code from MainDisplay, but it will not work in my case.

(3) MainDisplay must not simply replicate the traits in A, and then sync them. For example MainDisplay.dummy_i=Int(), then later in init, self.sync_traits('dummy_i',self.a,'i',mutual=True). Lastly use 'dummy_i' in MainDisplay.traits_view. This works as well, but again the MainDisplay class becomes so cluttered! Also, every time I want to change the GUI (or a trait), I have two places to edit, which slows down development.

I'm new to GUI's, but I feel like not being able to variables created at runtime is a strange and awkward restriction. My impression is that Enaml, which looks to replace traitsUI also has this restriction.

My main interest is displaying and interacting with 3D geometries created by Mayavi. Is it possible maybe PyQt doesn't have this restriction?

score 1 · Accepted Answer · answered Oct 25 '15 at 03:19

1

Within MainDisplay's view, you can refer to Item("object.a.i"), etc, where object is literally what you type (not a placeholder). This is described in the TraitsUI documentation's "Advanced View Concepts", section Multi-Object Views.

answered Oct 25 '15 at 03:19

Jonathan March

5,800
2
14
16

Fascinating. Thanks for the help. I'm sure I can make use of this in some cases, but I'm not altogether out of the woods. For example, if a.i is actually a range trait with high and low given by int traits also on a, say a.ceil_i,a.floor_i, then MainDisplay will complain that it is missing ceil_i, floor_i – user3391229 Oct 25 '15 at 03:27
Problem 2: This trick will not work if you try it on the member's group of traits instead of each trait individually. e.g. Item('object.a.a_group'). My guess is that if I never call a.configure_traits() that a_group never exists. – user3391229 Oct 25 '15 at 03:34
Not sure about your range example. For your second, to display a View within a View, use Instance(...) – Jonathan March Oct 25 '15 at 03:46
Johnathan, I don't quite understand how to use Instance here. I've tried all of the ways I could think of. Maybe I have a typo. Could you be more explicit? – user3391229 Oct 25 '15 at 04:05
Example here: https://github.com/enthought/traitsui/blob/master/examples/demo/Standard_Editors/InstanceEditor_demo.py – Jonathan March Oct 25 '15 at 04:13
Certainly that is a neat trick. I like it a lot. However I that differs from this example in two small ways. I think I can live with these, but I would like to make sure there's not something I'm missing. (1) I would be forced to rename 'a_display' into 'view' or 'traits_view' or something. This also I think implies that I can not incorporate more than one group from the same class. Say A inherits from A_parent. I would not be able to include both 'a_display' and 'a_parent_display' this way. (2) The resultant gui is a "popout" style. I would I think prefer to have everything in one window. – user3391229 Oct 25 '15 at 04:52
answer to (2) is to use style = 'custom' – user3391229 Oct 26 '15 at 15:47
Re (1) Yes you need a View, though it doesn't matter what you name it. I'm not aware of any way out of the box to specify different views for the same class, though I'm pretty sure that it could be done with a lot of work (defining a new editor). Generally a cleaner approach would be for each grouping that you want to treat as a unit to be specified as a distinct HasTraits subclass. – Jonathan March Oct 26 '15 at 18:06

Non-hacky solution for runtime created traits can't be displayed in View

1 Answers1