matplotlib-devel Mailing List for matplotlib

Hello everybody,
after happily using matplotlib for a while and writing a larger application for it with wxPython as the GUI toolkit, I recently tried to add a function to matplotlib itself. It is the possibility to interactively edit a plot, such that attributes of objects in a figure can be changed from the plot itself, in contrast to using a shell such as IPython.
This is of course inspired by Matlab and other tools. There are two ways to do this:
1. Provide graphical picking of objects, and dialogs and/or context menus to change attributes of the selected object(s). Advantages: most intuitive, perhaps also fastest to operate. Disadvantages: picking itself sometimes does not work well, and you can't click on what you don't see or know of.
2. Provide an 'object browser', i.e. a dialog that shows the tree of objects, where the user can select object(s), then inspect all attributes in another part of the dialog, and change them replacing content there. Advantages: delivers insight into the object structure, everything is easily found and selected. Disadvantages: often requires much more clicks, especially for simple changes.
Since the feature was always essential for me in Matlab, I naturally would like to have both solutions available concurrently, but when I tried to implement it, I decided for (2) because I wanted to know more about the object structure at first.
What I have right now is the 'object browser' in the WX backend, but without the actual editing feature, it is only possible to look at the objects and attributes. At this point I saw that I don't know matplotlib well enough to complete the editing myself. I'm overwhelmed by the variety of objects, attributes, methods, and distribution of items over the object tree.
I'm posting this because I would like to
* know if anybody is interested in this feature, too (couldn't find anything through searching the list).
* work together with you to make this something useful.
* get information about an appropriate way to integrate this into matplotlib (where to place the functions, etc.).
* finally see it integrated into a release, if possible.
Attached are a modified backend_wx.py of 0.98.3, and an icon for the toolbar2, to be included into ...\mpl-data\images. With these files, the icon appears on the toolbar2, and when clicked on, a dialog pops up. It shows the object tree on the left hand side, where items can be expanded, collapsed, and selected. For the selected object, the result of str(object.__dict__) is displayed on the right hand side. That's all ... only a start.
What's your opinion?
Regards,
Heinrich Acker

On Mon, Sep 15, 2008 at 07:38:01PM -0400, Paul Kienzle wrote:
> It does not poll.
> draw_idle() triggers a timer with a 5ms delay. This timer is reset for
> each draw_idle() call. At timeout the timer is restarted if there are more
> events on the wx event queue, otherwise the graph is rendered. This means
> you can do as many draw_idle commands as you want while processing your
> data, but the expensive rendering will only happen once.
OK, very nice. This is indeed a very efficient pattern for dealing with
too agressive refresh. I've seen it used with a lot of success in many
places. Thanks for enlighting me on this. I guess I could (should?) have
looked at the code base.
Gaël

On Mon, Sep 15, 2008 at 11:29:15PM +0200, Gael Varoquaux wrote:
> On Mon, Sep 15, 2008 at 04:06:45PM -0400, Paul Kienzle wrote:
> > Hi,
> 
> > I tweaked the wx backend so that the idle delay is 5 ms rather than 50 ms.
> > This allows the idle delay to kick in between mouse move events so
> > the graph will be updated during a drag operation.
> 
> > Users can override the idle delay using:
> 
> > mpl.backends.backend_wx.IDLE_DELAY = n
> 
> I don't know what the context is here, but if I understand it properly,
> to be doing polling on a 5ms timescale is not very nice. This means a
> wake up of the CPU every 5ms for this specific app. If everybody starts
> doing that (I am looking at you, flash) my battery life goes down and my
> laptop starts heating up.
It does not poll.
draw_idle() triggers a timer with a 5ms delay. This timer is reset for
each draw_idle() call. At timeout the timer is restarted if there are more
events on the wx event queue, otherwise the graph is rendered. This means
you can do as many draw_idle commands as you want while processing your
data, but the expensive rendering will only happen once.
Note that the wx.EVT_IDLE event polls about once per second. The 
backend must always bind to wx.EVT_IDLE since mpl_connect doesn't tell
it whether or not it wants to receive the events, so this can't
be avoided.
I'm including a demo program to check the idle event behaviour on
any platform, and the output I get on OS X when starting the
application, waiting a few seconds and moving the mouse. Wx is 
generating more events than I expect. 
Is there any reason to keep idle_event support? It would seems 
more useful to have timer+draw_idle.
 - Paul
-- idle.py --
import time
import pylab
t0 = time.time()
def idle(ev):
 print "idle event at time %.6f seconds"%(time.time()-t0)
def mouse(ev):
 print "motion event at time %.6f seconds"%(time.time()-t0)
pylab.plot([1,2,3])
pylab.gcf().canvas.mpl_connect('idle_event',idle)
pylab.gcf().canvas.mpl_connect('motion_notify_event',mouse)
pylab.show()
-- output --
$ python idle.py
idle event at time 0.564772 seconds
idle event at time 0.565030 seconds
idle event at time 0.565147 seconds
idle event at time 1.565512 seconds
idle event at time 1.565739 seconds
idle event at time 2.566126 seconds
idle event at time 2.566348 seconds
idle event at time 3.566702 seconds
idle event at time 3.566920 seconds
idle event at time 4.567263 seconds
idle event at time 4.567488 seconds
idle event at time 5.567894 seconds
idle event at time 5.568116 seconds
idle event at time 6.568480 seconds
idle event at time 6.568698 seconds
motion event at time 6.945880 seconds
idle event at time 6.946449 seconds
idle event at time 6.946573 seconds
idle event at time 6.946688 seconds
motion event at time 6.963200 seconds
idle event at time 6.963724 seconds
idle event at time 6.963845 seconds
idle event at time 6.963959 seconds
motion event at time 6.978130 seconds
idle event at time 6.978689 seconds
idle event at time 6.978846 seconds
idle event at time 6.978963 seconds
motion event at time 6.996028 seconds
idle event at time 6.996623 seconds
idle event at time 6.996751 seconds
idle event at time 6.996866 seconds

On Mon, Sep 15, 2008 at 04:06:45PM -0400, Paul Kienzle wrote:
> Hi,
> I tweaked the wx backend so that the idle delay is 5 ms rather than 50 ms.
> This allows the idle delay to kick in between mouse move events so
> the graph will be updated during a drag operation.
> Users can override the idle delay using:
> mpl.backends.backend_wx.IDLE_DELAY = n
I don't know what the context is here, but if I understand it properly,
to be doing polling on a 5ms timescale is not very nice. This means a
wake up of the CPU every 5ms for this specific app. If everybody starts
doing that (I am looking at you, flash) my battery life goes down and my
laptop starts heating up.
Gaël

Hi,
I tweaked the wx backend so that the idle delay is 5 ms rather than 50 ms.
This allows the idle delay to kick in between mouse move events so
the graph will be updated during a drag operation.
Users can override the idle delay using:
 mpl.backends.backend_wx.IDLE_DELAY = n
- Paul