[IPython-dev] Feasilibity of widgets/layout for mimicking this

[Nicholas Bollweg]

One way to do this would be to instead of requiring the notebook user to
understand everything, expose important bits as traitlets, and then
change/traitlet.link all of them together. In your example, if:

   - Plotting knows to redraw itself when its data changes
   - Filtering , updates its windowtype, to be, instead of "hamming",
   scipy.filter.hamming

then suddenly your code is now:

> def change_windowtype(name, old_value, new_value):
>     plot_ui.data = filtering_ui.windowtype(data)
> filtering_ui.on_trait_change("windowtype", change_windowtype)
>
(I don't think your usage of on_trait_changed as a decorator is legit, but
that would be awesome!)

That moves a lot of the event stuff into the internal structure of each of
your GUI components. This pattern would also be much easier to wrap up
later into a "higher order" GUI. Then, if you want to "hoist" a property,
you would just use traitlet.link:

> class GUI(widgets.ContainerWidget)
>     windowtype = traitlets.Any(sync=True)
>     plot_data = traitlets.Any(sync=True)
>     data = traitlets.Any(sync=True)
>
>     def __init__(self, **kwargs)
>         super(GUI, self).__init__(**kwargs)
>
>         self.filtering_ui = Filtering()
>         self.plot_ui = Plotting()
>
>         self.children = [self.filtering_ui, self.plot_ui]
>
>         traitlets.link(self, "plot_data"), (self.plot_ui, "data"),
>         traitlets.link(self, "windowtype"), (self.filtering_ui,
> "windowtype"),
>
>     def _windowtype_changed(self, name, old_value, new_value):
>         self.plot_data = self.windowtype(self.data)
>
And now the notebook user would still be able to inspect and change the
important parts of even deeply nested settings with simple assignment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140823/1ebcdc1f/attachment.html>