[IPython-dev] More widget feasibility ideas
hughesadam87 at gmail.com
Tue Dec 9 19:46:53 EST 2014
Thanks for all of your help on this. We were able to see it through and
put you in the acknowledgements:
On Thu, Oct 30, 2014 at 8:35 PM, Nicholas Bollweg <nick.bollweg at gmail.com>
> if there's nothing else going on there, that is correct!
> On Thu, Oct 30, 2014 at 1:38 PM, Adam Hughes <hughesadam87 at gmail.com>
>> So we can also drop the def displayed() / on_displayed portions of the
>> GUI, right?
>> On Thu, Oct 30, 2014 at 1:05 PM, Nicholas Bollweg <nick.bollweg at gmail.com
>> > wrote:
>>> You specify it when you create the instance:
>>> w = SomeWidget(_dom_classes=["panel-body"])
>>> or, in the case of class that should always get a _dom_class:
>>> class PanelBody(widgets.Box):
>>> def __init__(self, *args, **kwargs):
>>> super(PanelBody, self).__init__(*args, **kwargs)
>>> self._dom_classes += ("panel-body",)
>>> You could also monkey with the kwargs beforehand, avoiding, under the
>>> covers, two calls to update_classes, but this approach is easy to read,
>>> which i think wins out.
>>> When I asked about this on gitter, the reasoning for this change was
>>> that the add/remove class couldn't be made stateful, and that it was using
>>> extra, custom comms stuff to do something that traitlets were perfectly
>>> capable of. Thus, this traitlet. Howevever, as you can see from it having
>>> the _ prefix, this is really much more of a widget-developer functionality:
>>> not exactly simple.
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>> IPython-dev mailing list
>> IPython-dev at scipy.org
> IPython-dev mailing list
> IPython-dev at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev