[IPython-dev] Feasilibity of widgets/layout for mimicking this
Nicholas Bollweg
nick.bollweg at gmail.com
Sat Aug 23 15:50:25 EDT 2014
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>
More information about the IPython-dev
mailing list