Listening into a list not implemented?

[jdmarch]

Not urgent, maybe not even worth doing, but for the record: Final field does not change until first two are both non-empty:

defn MainWindow:
    Dialog:
        Container -> c:
            Field:
                value = ''
            Field:
                value = ''
            x = 'xyz'
            x << str([f.value for f in c.children])
        Field:
            value := c.x

[sccolbert]

This is not implemented (it's a very difficult thing to do right) and we should talk about whether we wan't to support it and whether or not there are legitimate use cases that would warrant it.

[jdmarch]

Perhaps not worth the effort, but the use case where I tried it was to listen for change in the validity of a container as the 'and' of the validity of its children.

[sccolbert]

On Sat, Nov 12, 2011 at 9:10 PM, Jonathan March < reply@reply.github.com

wrote:

Perhaps not worth the effort, but the use case where I tried it was to listen for change in the validity of a container as the 'and' of the validity of its children.

---

Reply to this email directly or view it on GitHub: https://github.com/enthought/enaml/issues/24#issuecomment-2720631

That may be logic you might want to push onto a Python model and have the various Enaml bits communicate with that model instead of trying to maintain all of the state themselves.

[rkern]

It would be cool if we could do something similar to extended trait change notifications:

Field:
    children:value >> setattr(self, 'x', str([f.value for f in children])

That may be putting too much of Traits semantics into the Enaml language, though.

[sccolbert]

This is the kind of thing for which custom operators were added ;-)

On Mon, Nov 14, 2011 at 5:33 AM, Robert Kern < reply@reply.github.com

wrote:

It would be cool if we could do something similar to extended trait change notifications:

Field: children:value >> setattr(self, 'x', str([f.value for f in children])

That may be putting too much of Traits semantics into the Enaml language, though.

---

Reply to this email directly or view it on GitHub: https://github.com/enthought/enaml/issues/24#issuecomment-2729407

[rkern]

So you're saying that we can make the default implementations as Traitsy as we like and consumers who don't want to think in Traits can use their own implementations? :-)

[sccolbert]

To a point, yes.

In this case, I still maintain that its probably better to keep this kind of state on a separate Python model rather than trying to force it on the view. So I don't think this situation is a good enough use case for us to define a new operator. If a valid use case comes along however, I certainly wouldn't be apposed to it.

The one thing we need to be careful of is this. The operators we define must remain easy to subclass. If the user defines their own operator, that operator must still understand traits since the RHS of the expression may include widget attributes, which are of course traits.

On Mon, Nov 14, 2011 at 10:27 AM, Robert Kern < reply@reply.github.com

wrote:

So you're saying that we can make the default implementations as Traitsy as we like and consumers who don't want to think in Traits can use their own implementations? :-)

---

Reply to this email directly or view it on GitHub: https://github.com/enthought/enaml/issues/24#issuecomment-2732494

[sccolbert]

just to update this, i have code in the works that will allow this and many other more complicated constructs to work as expected. There will be a performance hit for it, but it is negligible in comparison to the ui update that will take place because of it.

[sccolbert]

This is fixed in pr #64