Widget example that uses classes instead of globals?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Widget example that uses classes instead of globals?

hugadams
Hi,  

This question follows directly from this recent thread on the feasiblity of widgets (http://python.6.x6.nabble.com/Feasilibity-of-widgets-layout-for-mimicking-this-td5068197.html) but I thought was specific enough to be a new thread.

In all of the notebook examples I've seen, a GUI is defined in its own cell with global variables that are shared between functions.  I'd really like to see a complete, simple example of a GUI build as a class, where most of the events, updates and default values are set within the class.  And then when the class is instantiated, the notebook somehow can still output the GUI.

For example, would something of this design be compatible with the current widget design pattern:  

class Foo(object):

   variable = defaultvalue

   def update_variable(self):
      ....

   def redraw(self):
      ...

# Instantiate the class
f = Foo()
f.variable_widget.on_trait_change(update_variable, 'value')

Or is this type of design pattern out of the question?  We're trying to move in this direction so that we can compartmentalize and template as much behavior as possible, and make a simple framework for building up more complex GUIs.  It's just now clear to me if such a pattern is possible.  If anyone has any insights or examples, would you mind sharing?

THanks

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Widget example that uses classes instead of globals?

hugadams
And just to clarify, I presume that the notebook is actively "looking" for particular functions or something in the cell that let's the notebook know "hey, this is widget/GUI code, I need to output it as so".  I had worried that if this critical piece was buried in a class, the notebook wouldn't recognize it, and the GUI wouldn't display.


On Sat, Aug 30, 2014 at 1:41 PM, Adam Hughes <[hidden email]> wrote:
Hi,  

This question follows directly from this recent thread on the feasiblity of widgets (http://python.6.x6.nabble.com/Feasilibity-of-widgets-layout-for-mimicking-this-td5068197.html) but I thought was specific enough to be a new thread.

In all of the notebook examples I've seen, a GUI is defined in its own cell with global variables that are shared between functions.  I'd really like to see a complete, simple example of a GUI build as a class, where most of the events, updates and default values are set within the class.  And then when the class is instantiated, the notebook somehow can still output the GUI.

For example, would something of this design be compatible with the current widget design pattern:  

class Foo(object):

   variable = defaultvalue

   def update_variable(self):
      ....

   def redraw(self):
      ...

# Instantiate the class
f = Foo()
f.variable_widget.on_trait_change(update_variable, 'value')

Or is this type of design pattern out of the question?  We're trying to move in this direction so that we can compartmentalize and template as much behavior as possible, and make a simple framework for building up more complex GUIs.  It's just now clear to me if such a pattern is possible.  If anyone has any insights or examples, would you mind sharing?

THanks


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Widget example that uses classes instead of globals?

rossant
In reply to this post by hugadams
I think you can use the "display" function to render a widget instance, does that answer your question?

De : [hidden email]
Envoyé : ‎30/‎08/‎2014 18:43
À : [hidden email]
Objet : Re: [IPython-dev] Widget example that uses classes instead of globals?

And just to clarify, I presume that the notebook is actively "looking" for particular functions or something in the cell that let's the notebook know "hey, this is widget/GUI code, I need to output it as so".  I had worried that if this critical piece was buried in a class, the notebook wouldn't recognize it, and the GUI wouldn't display.


On Sat, Aug 30, 2014 at 1:41 PM, Adam Hughes <[hidden email]> wrote:
Hi,  

This question follows directly from this recent thread on the feasiblity of widgets (http://python.6.x6.nabble.com/Feasilibity-of-widgets-layout-for-mimicking-this-td5068197.html) but I thought was specific enough to be a new thread.

In all of the notebook examples I've seen, a GUI is defined in its own cell with global variables that are shared between functions.  I'd really like to see a complete, simple example of a GUI build as a class, where most of the events, updates and default values are set within the class.  And then when the class is instantiated, the notebook somehow can still output the GUI.

For example, would something of this design be compatible with the current widget design pattern:  

class Foo(object):

   variable = defaultvalue

   def update_variable(self):
      ....

   def redraw(self):
      ...

# Instantiate the class
f = Foo()
f.variable_widget.on_trait_change(update_variable, 'value')

Or is this type of design pattern out of the question?  We're trying to move in this direction so that we can compartmentalize and template as much behavior as possible, and make a simple framework for building up more complex GUIs.  It's just now clear to me if such a pattern is possible.  If anyone has any insights or examples, would you mind sharing?

THanks


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Widget example that uses classes instead of globals?

Antonino Ingargiola
Hi,

Sorry for entering in the discussion on-fly...

My question is more specific (but possibly very similar). Would be possible to call interact with a class object (i.e. a callable class) instead of a function? This would allow to store all the GUI specific state in the class (for example precomputing figures) without the need of using globals.

When I quickly tried (with ipython 2.2), interact returned an error complaining about the number of parameters passed to the object. So I resorted to using globals. Below I attached the code I currently use to pre-compute a set of figures (a slider selects which figure to display). I would appreciate any comment on possibly improving this pattern.

fig_cache = {}
def plot_mfit_i(ich=0, nodisplay=False):
    global fig_cache
    if ich not in fig_cache:
        fig = mfit.plot_mfit(fitter, ich=ich, residuals=True, return_fig=True)
        fig_cache[ich] = fig
        plt.close(fig)
    if not nodisplay:
        display(fig_cache[ich])

for i in range(8): plot_mfit_i(i, nodisplay=True)  # Precompute all the figures

interact(plot_mfit_i, ich=(0, 7), nodisplay=fixed(False));  # display the figure selected through the slider

--
Antonio

On Sat, Aug 30, 2014 at 10:49 AM, Cyrille Rossant <[hidden email]> wrote:
I think you can use the "display" function to render a widget instance, does that answer your question?

De : [hidden email]
Envoyé : ‎30/‎08/‎2014 18:43
À : [hidden email]
Objet : Re: [IPython-dev] Widget example that uses classes instead of globals?

And just to clarify, I presume that the notebook is actively "looking" for particular functions or something in the cell that let's the notebook know "hey, this is widget/GUI code, I need to output it as so".  I had worried that if this critical piece was buried in a class, the notebook wouldn't recognize it, and the GUI wouldn't display.


On Sat, Aug 30, 2014 at 1:41 PM, Adam Hughes <[hidden email]> wrote:
Hi,  

This question follows directly from this recent thread on the feasiblity of widgets (http://python.6.x6.nabble.com/Feasilibity-of-widgets-layout-for-mimicking-this-td5068197.html) but I thought was specific enough to be a new thread.

In all of the notebook examples I've seen, a GUI is defined in its own cell with global variables that are shared between functions.  I'd really like to see a complete, simple example of a GUI build as a class, where most of the events, updates and default values are set within the class.  And then when the class is instantiated, the notebook somehow can still output the GUI.

For example, would something of this design be compatible with the current widget design pattern:  

class Foo(object):

   variable = defaultvalue

   def update_variable(self):
      ....

   def redraw(self):
      ...

# Instantiate the class
f = Foo()
f.variable_widget.on_trait_change(update_variable, 'value')

Or is this type of design pattern out of the question?  We're trying to move in this direction so that we can compartmentalize and template as much behavior as possible, and make a simple framework for building up more complex GUIs.  It's just now clear to me if such a pattern is possible.  If anyone has any insights or examples, would you mind sharing?

THanks


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Widget example that uses classes instead of globals?

Nicholas Bollweg
@antonino: I hadn't thought to use interact that way! __call__ might be too magic to be used that way... but you can create a non-bound function (not a method, though self would be in scope!) in the constructor of a widget that will respond to interact:

from IPython.html.widgets import interact, ContainerWidget, HTMLWidget

class Carousel(ContainerWidget):
    def __init__(self, *args, **kwargs):
        self.might_show = [HTMLWidget(value="<h1>%s</h1>" % i) for i in range(10)]
        super(Carousel, self).__init__(*args, **kwargs)
       
        def interact(n):
            self.children = [self.might_show[n]]
       
        self.show = show

carousel = Carousel()
interact(carousel.
interact, n=(0, len(carousel.might_show)-1))
carousel


I don't know much about how matplotlib interacts with widgets/traitlets... but presumably the ImageWidget will accept them as its value.

You could move even more behavior into the class itself, but eventually one would likely need something more complicated than what interact provides out of the box...

@adam: Sorry it took me a while to respond. Here is an updated version of the fake GUI, implemented as a series of classes: a standalone graph, a couple reusable control components and the full-blown end user GUI. I tried to put a few examples of different techniques in that we have used: link, on_trait_changed, CSS, Bootstrap. I didn't do any custom Backbone, as that is a whole other kettle of fish.

http://nbviewer.ipython.org/gist/bollwyvl/ddd4bf5d7c879012fa2c

There are a few more gotchas that would come along with this, such as installing assets, if you end up using them, but there are a good number of threads/examples out there for install_nbextension/load_nbextensions. In a pinch, you could even cheat and have an HTML embed the style directly, I guess!

I didn't use the "wire" concept from before: while it has proven useful for quickly hacking stuff together, i have found it might be a bit "cute" for something that one actually wanted to release and/or expect people to be able to extend. If i can figure out how to get it to easily un-listen for things, it might be work saving, but in the meantime link and on_trait_changed are good enough!

Hope this helps!

On Sat, Aug 30, 2014 at 2:21 PM, Antonino Ingargiola <[hidden email]> wrote:
Hi,

Sorry for entering in the discussion on-fly...

My question is more specific (but possibly very similar). Would be possible to call interact with a class object (i.e. a callable class) instead of a function? This would allow to store all the GUI specific state in the class (for example precomputing figures) without the need of using globals.

When I quickly tried (with ipython 2.2), interact returned an error complaining about the number of parameters passed to the object. So I resorted to using globals. Below I attached the code I currently use to pre-compute a set of figures (a slider selects which figure to display). I would appreciate any comment on possibly improving this pattern.

fig_cache = {}
def plot_mfit_i(ich=0, nodisplay=False):
    global fig_cache
    if ich not in fig_cache:
        fig = mfit.plot_mfit(fitter, ich=ich, residuals=True, return_fig=True)
        fig_cache[ich] = fig
        plt.close(fig)
    if not nodisplay:
        display(fig_cache[ich])

for i in range(8): plot_mfit_i(i, nodisplay=True)  # Precompute all the figures

interact(plot_mfit_i, ich=(0, 7), nodisplay=fixed(False));  # display the figure selected through the slider

--
Antonio

On Sat, Aug 30, 2014 at 10:49 AM, Cyrille Rossant <[hidden email]> wrote:
I think you can use the "display" function to render a widget instance, does that answer your question?

De : [hidden email]
Envoyé : ‎30/‎08/‎2014 18:43
À : [hidden email]
Objet : Re: [IPython-dev] Widget example that uses classes instead of globals?

And just to clarify, I presume that the notebook is actively "looking" for particular functions or something in the cell that let's the notebook know "hey, this is widget/GUI code, I need to output it as so".  I had worried that if this critical piece was buried in a class, the notebook wouldn't recognize it, and the GUI wouldn't display.


On Sat, Aug 30, 2014 at 1:41 PM, Adam Hughes <[hidden email]> wrote:
Hi,  

This question follows directly from this recent thread on the feasiblity of widgets (http://python.6.x6.nabble.com/Feasilibity-of-widgets-layout-for-mimicking-this-td5068197.html) but I thought was specific enough to be a new thread.

In all of the notebook examples I've seen, a GUI is defined in its own cell with global variables that are shared between functions.  I'd really like to see a complete, simple example of a GUI build as a class, where most of the events, updates and default values are set within the class.  And then when the class is instantiated, the notebook somehow can still output the GUI.

For example, would something of this design be compatible with the current widget design pattern:  

class Foo(object):

   variable = defaultvalue

   def update_variable(self):
      ....

   def redraw(self):
      ...

# Instantiate the class
f = Foo()
f.variable_widget.on_trait_change(update_variable, 'value')

Or is this type of design pattern out of the question?  We're trying to move in this direction so that we can compartmentalize and template as much behavior as possible, and make a simple framework for building up more complex GUIs.  It's just now clear to me if such a pattern is possible.  If anyone has any insights or examples, would you mind sharing?

THanks


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Widget example that uses classes instead of globals?

hugadams
Nicholas,

This is an amazing example.  Thanks so much for helping us this much!  Will send you some updates when we are able to get it running with our data and credit you in this.  Is there a special way you'd like to be acknowledged or cited?

On Mon, Sep 15, 2014 at 11:19 PM, Nicholas Bollweg <[hidden email]> wrote:
@antonino: I hadn't thought to use interact that way! __call__ might be too magic to be used that way... but you can create a non-bound function (not a method, though self would be in scope!) in the constructor of a widget that will respond to interact:

from IPython.html.widgets import interact, ContainerWidget, HTMLWidget

class Carousel(ContainerWidget):
    def __init__(self, *args, **kwargs):
        self.might_show = [HTMLWidget(value="<h1>%s</h1>" % i) for i in range(10)]
        super(Carousel, self).__init__(*args, **kwargs)
       
        def interact(n):
            self.children = [self.might_show[n]]
       
        self.show = show

carousel = Carousel()
interact(carousel.
interact, n=(0, len(carousel.might_show)-1))
carousel


I don't know much about how matplotlib interacts with widgets/traitlets... but presumably the ImageWidget will accept them as its value.

You could move even more behavior into the class itself, but eventually one would likely need something more complicated than what interact provides out of the box...

@adam: Sorry it took me a while to respond. Here is an updated version of the fake GUI, implemented as a series of classes: a standalone graph, a couple reusable control components and the full-blown end user GUI. I tried to put a few examples of different techniques in that we have used: link, on_trait_changed, CSS, Bootstrap. I didn't do any custom Backbone, as that is a whole other kettle of fish.

http://nbviewer.ipython.org/gist/bollwyvl/ddd4bf5d7c879012fa2c

There are a few more gotchas that would come along with this, such as installing assets, if you end up using them, but there are a good number of threads/examples out there for install_nbextension/load_nbextensions. In a pinch, you could even cheat and have an HTML embed the style directly, I guess!

I didn't use the "wire" concept from before: while it has proven useful for quickly hacking stuff together, i have found it might be a bit "cute" for something that one actually wanted to release and/or expect people to be able to extend. If i can figure out how to get it to easily un-listen for things, it might be work saving, but in the meantime link and on_trait_changed are good enough!

Hope this helps!

On Sat, Aug 30, 2014 at 2:21 PM, Antonino Ingargiola <[hidden email]> wrote:
Hi,

Sorry for entering in the discussion on-fly...

My question is more specific (but possibly very similar). Would be possible to call interact with a class object (i.e. a callable class) instead of a function? This would allow to store all the GUI specific state in the class (for example precomputing figures) without the need of using globals.

When I quickly tried (with ipython 2.2), interact returned an error complaining about the number of parameters passed to the object. So I resorted to using globals. Below I attached the code I currently use to pre-compute a set of figures (a slider selects which figure to display). I would appreciate any comment on possibly improving this pattern.

fig_cache = {}
def plot_mfit_i(ich=0, nodisplay=False):
    global fig_cache
    if ich not in fig_cache:
        fig = mfit.plot_mfit(fitter, ich=ich, residuals=True, return_fig=True)
        fig_cache[ich] = fig
        plt.close(fig)
    if not nodisplay:
        display(fig_cache[ich])

for i in range(8): plot_mfit_i(i, nodisplay=True)  # Precompute all the figures

interact(plot_mfit_i, ich=(0, 7), nodisplay=fixed(False));  # display the figure selected through the slider

--
Antonio

On Sat, Aug 30, 2014 at 10:49 AM, Cyrille Rossant <[hidden email]> wrote:
I think you can use the "display" function to render a widget instance, does that answer your question?

De : [hidden email]
Envoyé : ‎30/‎08/‎2014 18:43
À : [hidden email]
Objet : Re: [IPython-dev] Widget example that uses classes instead of globals?

And just to clarify, I presume that the notebook is actively "looking" for particular functions or something in the cell that let's the notebook know "hey, this is widget/GUI code, I need to output it as so".  I had worried that if this critical piece was buried in a class, the notebook wouldn't recognize it, and the GUI wouldn't display.


On Sat, Aug 30, 2014 at 1:41 PM, Adam Hughes <[hidden email]> wrote:
Hi,  

This question follows directly from this recent thread on the feasiblity of widgets (http://python.6.x6.nabble.com/Feasilibity-of-widgets-layout-for-mimicking-this-td5068197.html) but I thought was specific enough to be a new thread.

In all of the notebook examples I've seen, a GUI is defined in its own cell with global variables that are shared between functions.  I'd really like to see a complete, simple example of a GUI build as a class, where most of the events, updates and default values are set within the class.  And then when the class is instantiated, the notebook somehow can still output the GUI.

For example, would something of this design be compatible with the current widget design pattern:  

class Foo(object):

   variable = defaultvalue

   def update_variable(self):
      ....

   def redraw(self):
      ...

# Instantiate the class
f = Foo()
f.variable_widget.on_trait_change(update_variable, 'value')

Or is this type of design pattern out of the question?  We're trying to move in this direction so that we can compartmentalize and template as much behavior as possible, and make a simple framework for building up more complex GUIs.  It's just now clear to me if such a pattern is possible.  If anyone has any insights or examples, would you mind sharing?

THanks


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Widget example that uses classes instead of globals?

Brian Granger-3
https://github.com/ellisonbg/leaftletwidget/blob/master/leafletwidget/leaflet.py#L19

This mixin provides an interact method that allows you to interact
with any traitlet on a class. Just haven't had time to turn this into
a proper ipython PR...

On Tue, Sep 16, 2014 at 11:27 AM, Adam Hughes <[hidden email]> wrote:

> Nicholas,
>
> This is an amazing example.  Thanks so much for helping us this much!  Will
> send you some updates when we are able to get it running with our data and
> credit you in this.  Is there a special way you'd like to be acknowledged or
> cited?
>
> On Mon, Sep 15, 2014 at 11:19 PM, Nicholas Bollweg <[hidden email]>
> wrote:
>>
>> @antonino: I hadn't thought to use interact that way! __call__ might be
>> too magic to be used that way... but you can create a non-bound function
>> (not a method, though self would be in scope!) in the constructor of a
>> widget that will respond to interact:
>>
>>> from IPython.html.widgets import interact, ContainerWidget, HTMLWidget
>>>
>>> class Carousel(ContainerWidget):
>>>     def __init__(self, *args, **kwargs):
>>>         self.might_show = [HTMLWidget(value="<h1>%s</h1>" % i) for i in
>>> range(10)]
>>>         super(Carousel, self).__init__(*args, **kwargs)
>>>
>>>         def interact(n):
>>>             self.children = [self.might_show[n]]
>>>
>>>         self.show = show
>>>
>>> carousel = Carousel()
>>> interact(carousel.interact, n=(0, len(carousel.might_show)-1))
>>> carousel
>>
>>
>> I don't know much about how matplotlib interacts with widgets/traitlets...
>> but presumably the ImageWidget will accept them as its value.
>>
>> You could move even more behavior into the class itself, but eventually
>> one would likely need something more complicated than what interact provides
>> out of the box...
>>
>> @adam: Sorry it took me a while to respond. Here is an updated version of
>> the fake GUI, implemented as a series of classes: a standalone graph, a
>> couple reusable control components and the full-blown end user GUI. I tried
>> to put a few examples of different techniques in that we have used: link,
>> on_trait_changed, CSS, Bootstrap. I didn't do any custom Backbone, as that
>> is a whole other kettle of fish.
>>
>>> http://nbviewer.ipython.org/gist/bollwyvl/ddd4bf5d7c879012fa2c
>>
>>
>> There are a few more gotchas that would come along with this, such as
>> installing assets, if you end up using them, but there are a good number of
>> threads/examples out there for install_nbextension/load_nbextensions. In a
>> pinch, you could even cheat and have an HTML embed the style directly, I
>> guess!
>>
>> I didn't use the "wire" concept from before: while it has proven useful
>> for quickly hacking stuff together, i have found it might be a bit "cute"
>> for something that one actually wanted to release and/or expect people to be
>> able to extend. If i can figure out how to get it to easily un-listen for
>> things, it might be work saving, but in the meantime link and
>> on_trait_changed are good enough!
>>
>> Hope this helps!
>>
>> On Sat, Aug 30, 2014 at 2:21 PM, Antonino Ingargiola <[hidden email]>
>> wrote:
>>>
>>> Hi,
>>>
>>> Sorry for entering in the discussion on-fly...
>>>
>>> My question is more specific (but possibly very similar). Would be
>>> possible to call interact with a class object (i.e. a callable class)
>>> instead of a function? This would allow to store all the GUI specific state
>>> in the class (for example precomputing figures) without the need of using
>>> globals.
>>>
>>> When I quickly tried (with ipython 2.2), interact returned an error
>>> complaining about the number of parameters passed to the object. So I
>>> resorted to using globals. Below I attached the code I currently use to
>>> pre-compute a set of figures (a slider selects which figure to display). I
>>> would appreciate any comment on possibly improving this pattern.
>>>
>>> fig_cache = {}
>>> def plot_mfit_i(ich=0, nodisplay=False):
>>>     global fig_cache
>>>     if ich not in fig_cache:
>>>         fig = mfit.plot_mfit(fitter, ich=ich, residuals=True,
>>> return_fig=True)
>>>         fig_cache[ich] = fig
>>>         plt.close(fig)
>>>     if not nodisplay:
>>>         display(fig_cache[ich])
>>>
>>> for i in range(8): plot_mfit_i(i, nodisplay=True)  # Precompute all the
>>> figures
>>>
>>> interact(plot_mfit_i, ich=(0, 7), nodisplay=fixed(False));  # display the
>>> figure selected through the slider
>>>
>>> --
>>> Antonio
>>>
>>> On Sat, Aug 30, 2014 at 10:49 AM, Cyrille Rossant
>>> <[hidden email]> wrote:
>>>>
>>>> I think you can use the "display" function to render a widget instance,
>>>> does that answer your question?
>>>> ________________________________
>>>> De : Adam Hughes
>>>> Envoyé : ‎30/‎08/‎2014 18:43
>>>> À : IPython developers list
>>>> Objet : Re: [IPython-dev] Widget example that uses classes instead of
>>>> globals?
>>>>
>>>> And just to clarify, I presume that the notebook is actively "looking"
>>>> for particular functions or something in the cell that let's the notebook
>>>> know "hey, this is widget/GUI code, I need to output it as so".  I had
>>>> worried that if this critical piece was buried in a class, the notebook
>>>> wouldn't recognize it, and the GUI wouldn't display.
>>>>
>>>>
>>>> On Sat, Aug 30, 2014 at 1:41 PM, Adam Hughes <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> This question follows directly from this recent thread on the
>>>>> feasiblity of widgets
>>>>> (http://python.6.x6.nabble.com/Feasilibity-of-widgets-layout-for-mimicking-this-td5068197.html)
>>>>> but I thought was specific enough to be a new thread.
>>>>>
>>>>> In all of the notebook examples I've seen, a GUI is defined in its own
>>>>> cell with global variables that are shared between functions.  I'd really
>>>>> like to see a complete, simple example of a GUI build as a class, where most
>>>>> of the events, updates and default values are set within the class.  And
>>>>> then when the class is instantiated, the notebook somehow can still output
>>>>> the GUI.
>>>>>
>>>>> For example, would something of this design be compatible with the
>>>>> current widget design pattern:
>>>>>
>>>>> class Foo(object):
>>>>>
>>>>>    variable = defaultvalue
>>>>>
>>>>>    def update_variable(self):
>>>>>       ....
>>>>>
>>>>>    def redraw(self):
>>>>>       ...
>>>>>
>>>>> # Instantiate the class
>>>>> f = Foo()
>>>>> f.variable_widget.on_trait_change(update_variable, 'value')
>>>>>
>>>>> Or is this type of design pattern out of the question?  We're trying to
>>>>> move in this direction so that we can compartmentalize and template as much
>>>>> behavior as possible, and make a simple framework for building up more
>>>>> complex GUIs.  It's just now clear to me if such a pattern is possible.  If
>>>>> anyone has any insights or examples, would you mind sharing?
>>>>>
>>>>> THanks
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> [hidden email]
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> [hidden email]
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> [hidden email]
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[hidden email] and [hidden email]
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Widget example that uses classes instead of globals?

hugadams
Brian, thanks.  I am a bit overwhelmed with the amount of info I'm receiving, so will need some time to parse it all.  Looking forward to getting my feet wet.

On Tue, Sep 16, 2014 at 3:10 PM, Brian Granger <[hidden email]> wrote:
https://github.com/ellisonbg/leaftletwidget/blob/master/leafletwidget/leaflet.py#L19

This mixin provides an interact method that allows you to interact
with any traitlet on a class. Just haven't had time to turn this into
a proper ipython PR...

On Tue, Sep 16, 2014 at 11:27 AM, Adam Hughes <[hidden email]> wrote:
> Nicholas,
>
> This is an amazing example.  Thanks so much for helping us this much!  Will
> send you some updates when we are able to get it running with our data and
> credit you in this.  Is there a special way you'd like to be acknowledged or
> cited?
>
> On Mon, Sep 15, 2014 at 11:19 PM, Nicholas Bollweg <[hidden email]>
> wrote:
>>
>> @antonino: I hadn't thought to use interact that way! __call__ might be
>> too magic to be used that way... but you can create a non-bound function
>> (not a method, though self would be in scope!) in the constructor of a
>> widget that will respond to interact:
>>
>>> from IPython.html.widgets import interact, ContainerWidget, HTMLWidget
>>>
>>> class Carousel(ContainerWidget):
>>>     def __init__(self, *args, **kwargs):
>>>         self.might_show = [HTMLWidget(value="<h1>%s</h1>" % i) for i in
>>> range(10)]
>>>         super(Carousel, self).__init__(*args, **kwargs)
>>>
>>>         def interact(n):
>>>             self.children = [self.might_show[n]]
>>>
>>>         self.show = show
>>>
>>> carousel = Carousel()
>>> interact(carousel.interact, n=(0, len(carousel.might_show)-1))
>>> carousel
>>
>>
>> I don't know much about how matplotlib interacts with widgets/traitlets...
>> but presumably the ImageWidget will accept them as its value.
>>
>> You could move even more behavior into the class itself, but eventually
>> one would likely need something more complicated than what interact provides
>> out of the box...
>>
>> @adam: Sorry it took me a while to respond. Here is an updated version of
>> the fake GUI, implemented as a series of classes: a standalone graph, a
>> couple reusable control components and the full-blown end user GUI. I tried
>> to put a few examples of different techniques in that we have used: link,
>> on_trait_changed, CSS, Bootstrap. I didn't do any custom Backbone, as that
>> is a whole other kettle of fish.
>>
>>> http://nbviewer.ipython.org/gist/bollwyvl/ddd4bf5d7c879012fa2c
>>
>>
>> There are a few more gotchas that would come along with this, such as
>> installing assets, if you end up using them, but there are a good number of
>> threads/examples out there for install_nbextension/load_nbextensions. In a
>> pinch, you could even cheat and have an HTML embed the style directly, I
>> guess!
>>
>> I didn't use the "wire" concept from before: while it has proven useful
>> for quickly hacking stuff together, i have found it might be a bit "cute"
>> for something that one actually wanted to release and/or expect people to be
>> able to extend. If i can figure out how to get it to easily un-listen for
>> things, it might be work saving, but in the meantime link and
>> on_trait_changed are good enough!
>>
>> Hope this helps!
>>
>> On Sat, Aug 30, 2014 at 2:21 PM, Antonino Ingargiola <[hidden email]>
>> wrote:
>>>
>>> Hi,
>>>
>>> Sorry for entering in the discussion on-fly...
>>>
>>> My question is more specific (but possibly very similar). Would be
>>> possible to call interact with a class object (i.e. a callable class)
>>> instead of a function? This would allow to store all the GUI specific state
>>> in the class (for example precomputing figures) without the need of using
>>> globals.
>>>
>>> When I quickly tried (with ipython 2.2), interact returned an error
>>> complaining about the number of parameters passed to the object. So I
>>> resorted to using globals. Below I attached the code I currently use to
>>> pre-compute a set of figures (a slider selects which figure to display). I
>>> would appreciate any comment on possibly improving this pattern.
>>>
>>> fig_cache = {}
>>> def plot_mfit_i(ich=0, nodisplay=False):
>>>     global fig_cache
>>>     if ich not in fig_cache:
>>>         fig = mfit.plot_mfit(fitter, ich=ich, residuals=True,
>>> return_fig=True)
>>>         fig_cache[ich] = fig
>>>         plt.close(fig)
>>>     if not nodisplay:
>>>         display(fig_cache[ich])
>>>
>>> for i in range(8): plot_mfit_i(i, nodisplay=True)  # Precompute all the
>>> figures
>>>
>>> interact(plot_mfit_i, ich=(0, 7), nodisplay=fixed(False));  # display the
>>> figure selected through the slider
>>>
>>> --
>>> Antonio
>>>
>>> On Sat, Aug 30, 2014 at 10:49 AM, Cyrille Rossant
>>> <[hidden email]> wrote:
>>>>
>>>> I think you can use the "display" function to render a widget instance,
>>>> does that answer your question?
>>>> ________________________________
>>>> De : Adam Hughes
>>>> Envoyé : ‎30/‎08/‎2014 18:43
>>>> À : IPython developers list
>>>> Objet : Re: [IPython-dev] Widget example that uses classes instead of
>>>> globals?
>>>>
>>>> And just to clarify, I presume that the notebook is actively "looking"
>>>> for particular functions or something in the cell that let's the notebook
>>>> know "hey, this is widget/GUI code, I need to output it as so".  I had
>>>> worried that if this critical piece was buried in a class, the notebook
>>>> wouldn't recognize it, and the GUI wouldn't display.
>>>>
>>>>
>>>> On Sat, Aug 30, 2014 at 1:41 PM, Adam Hughes <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> This question follows directly from this recent thread on the
>>>>> feasiblity of widgets
>>>>> (http://python.6.x6.nabble.com/Feasilibity-of-widgets-layout-for-mimicking-this-td5068197.html)
>>>>> but I thought was specific enough to be a new thread.
>>>>>
>>>>> In all of the notebook examples I've seen, a GUI is defined in its own
>>>>> cell with global variables that are shared between functions.  I'd really
>>>>> like to see a complete, simple example of a GUI build as a class, where most
>>>>> of the events, updates and default values are set within the class.  And
>>>>> then when the class is instantiated, the notebook somehow can still output
>>>>> the GUI.
>>>>>
>>>>> For example, would something of this design be compatible with the
>>>>> current widget design pattern:
>>>>>
>>>>> class Foo(object):
>>>>>
>>>>>    variable = defaultvalue
>>>>>
>>>>>    def update_variable(self):
>>>>>       ....
>>>>>
>>>>>    def redraw(self):
>>>>>       ...
>>>>>
>>>>> # Instantiate the class
>>>>> f = Foo()
>>>>> f.variable_widget.on_trait_change(update_variable, 'value')
>>>>>
>>>>> Or is this type of design pattern out of the question?  We're trying to
>>>>> move in this direction so that we can compartmentalize and template as much
>>>>> behavior as possible, and make a simple framework for building up more
>>>>> complex GUIs.  It's just now clear to me if such a pattern is possible.  If
>>>>> anyone has any insights or examples, would you mind sharing?
>>>>>
>>>>> THanks
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> [hidden email]
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> [hidden email]
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> [hidden email]
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[hidden email] and [hidden email]
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Widget example that uses classes instead of globals?

Fernando Perez
In reply to this post by Nicholas Bollweg

On Mon, Sep 15, 2014 at 8:19 PM, Nicholas Bollweg <[hidden email]> wrote:
@adam: Sorry it took me a while to respond. Here is an updated version of the fake GUI, implemented as a series of classes: a standalone graph, a couple reusable control components and the full-blown end user GUI. I tried to put a few examples of different techniques in that we have used: link, on_trait_changed, CSS, Bootstrap. I didn't do any custom Backbone, as that is a whole other kettle of fish.

http://nbviewer.ipython.org/gist/bollwyvl/ddd4bf5d7c879012fa2c

Wonderful example, thanks Nicholas!

I've made a minimally modified version here:


just to illustrate how to actually plot data in the 'plot area' with matplotlib.

I may use this in a talk I'm giving tomorrow, if so I'll do so with full credit to you.

Thanks for sharing!

f


--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Widget example that uses classes instead of globals?

Nicholas Bollweg
@adam
No problem, no special acknowledgement necessary! The credit goes to the creators of the Notebook and its ecosystem (bootstrap, backbone, etc): as a user, I feel much better about the result of this little exercise vs. other forays into, say, wx, Flash/Flex,  to create similar things. Certainly do keep us posted on your progress!

@brian
leafletwidget: i've needed this in the past! thanks for the link!
offtopic: where's the bower.io for widgets!? how would it look in the jupyter future?
the mixin looks better for antonino's broader question, as well.
Do you like the approach you have taken for treating the widget js as a template, inserted into the notebook output? is this a better way to do it than load_extensons? will this be better for static widgets, or will stuff from load_extensions be included?

@fernando
Making it less notional is a great upgrade, and i'll likely add a link to your expanded version. I think we still want some examples that are even less notional (i.e. useful!), but happy to help!

On Tue, Sep 16, 2014 at 3:22 PM, Fernando Perez <[hidden email]> wrote:

On Mon, Sep 15, 2014 at 8:19 PM, Nicholas Bollweg <[hidden email]> wrote:
@adam: Sorry it took me a while to respond. Here is an updated version of the fake GUI, implemented as a series of classes: a standalone graph, a couple reusable control components and the full-blown end user GUI. I tried to put a few examples of different techniques in that we have used: link, on_trait_changed, CSS, Bootstrap. I didn't do any custom Backbone, as that is a whole other kettle of fish.

http://nbviewer.ipython.org/gist/bollwyvl/ddd4bf5d7c879012fa2c

Wonderful example, thanks Nicholas!

I've made a minimally modified version here:


just to illustrate how to actually plot data in the 'plot area' with matplotlib.

I may use this in a talk I'm giving tomorrow, if so I'll do so with full credit to you.

Thanks for sharing!

f


--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Widget example that uses classes instead of globals?

hugadams
In reply to this post by Fernando Perez
I wanted to share a bit of context for this example, since it has been seen by several of you on the list.

We are looking to implement a spectroscopy field called two-dimensional correlation analysis.  I spoke with the founder of the subject, and he said he's only aware of a small, windows program that essentially is this GUI.  In fact, the original screenshot I sent was from that small program.  A matlab program called MIDAS also did a really job of porting some 2DCS principles.  We've built 2DCS directly into our new spectroscopy library, so being able to give users a GUI-driven experience ON TOP OF the pandas-based API is our golden ticket.  This vision of GUI when you want it, API when you need it in the notebook I hope will catch on.  I really am appreciative of all of the help you guys gave me on this thread an hope to deliver.

Here is the analysis through the API if it's interesting to anyone.


This is also just an incomplete draft.

On Tue, Sep 16, 2014 at 3:22 PM, Fernando Perez <[hidden email]> wrote:

On Mon, Sep 15, 2014 at 8:19 PM, Nicholas Bollweg <[hidden email]> wrote:
@adam: Sorry it took me a while to respond. Here is an updated version of the fake GUI, implemented as a series of classes: a standalone graph, a couple reusable control components and the full-blown end user GUI. I tried to put a few examples of different techniques in that we have used: link, on_trait_changed, CSS, Bootstrap. I didn't do any custom Backbone, as that is a whole other kettle of fish.

http://nbviewer.ipython.org/gist/bollwyvl/ddd4bf5d7c879012fa2c

Wonderful example, thanks Nicholas!

I've made a minimally modified version here:


just to illustrate how to actually plot data in the 'plot area' with matplotlib.

I may use this in a talk I'm giving tomorrow, if so I'll do so with full credit to you.

Thanks for sharing!

f


--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev