Thread: [Matplotlib-users] executing function when view interval changes

Hi everyone,

I wish to execute a certain function every time the view interval of  
a figure is updated, for example when it is changed interactively  
using the zoom rectangle or home button in WXAgg. Matplotlib must  
already be calling certain routines, such as the tick locator and  
formatters, but is there a way to execute arbitrary functions when  
the view interval is updated?

Thanks for any help,

Thomas

On Wed, Feb 11, 2009 at 2:34 PM, Thomas Robitaille <
tho...@gm...> wrote:

> Hi everyone,
>
> I wish to execute a certain function every time the view interval of
> a figure is updated, for example when it is changed interactively
> using the zoom rectangle or home button in WXAgg. Matplotlib must
> already be calling certain routines, such as the tick locator and
> formatters, but is there a way to execute arbitrary functions when
> the view interval is updated?


You're looking for 'xlim_changed' and 'ylim_changed'.

 I know this can be found here:
http://matplotlib.sourceforge.net/api/axes_api.html

Should we add this to
http://matplotlib.sourceforge.net/users/event_handling.html ?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rm...@gm...> wrote:

> You're looking for 'xlim_changed' and 'ylim_changed'.
>
>  I know this can be found here:
> http://matplotlib.sourceforge.net/api/axes_api.html
>
> Should we add this to
> http://matplotlib.sourceforge.net/users/event_handling.html ?

We should - perhaps you can prepare a small example ( I notice we
don't have any) illustrating it and add a description with a pointer
to the example in the event handling tutorial.

JDH

On Wed, Feb 11, 2009 at 7:30 PM, John Hunter <jd...@gm...> wrote:

> On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rm...@gm...> wrote:
>
> > You're looking for 'xlim_changed' and 'ylim_changed'.
> >
> >  I know this can be found here:
> > http://matplotlib.sourceforge.net/api/axes_api.html
> >
> > Should we add this to
> > http://matplotlib.sourceforge.net/users/event_handling.html ?
>
> We should - perhaps you can prepare a small example ( I notice we
> don't have any) illustrating it and add a description with a pointer
> to the example in the event handling tutorial.
>
> JDH
>

Well, I checked in an example that shows the functionality.  The problem is
that using these events doesn't follow the standard event API.  You don't
connect using figure.canvas.mpl_connect() (it doesn't like the names
'xlim_changed' and 'ylim_changed'), but rather you use
Axes.callbacks.connect().  Also, the an event object is not passed into the
callback, but rather the originating axes instance.  Are these events relics
to the older version of event handling that haven't been moved to the
present?

Otherwise, should I add a special section to the event handling docs to
handle these?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

On Thu, Feb 12, 2009 at 2:13 PM, Ryan May <rm...@gm...> wrote:
> On Wed, Feb 11, 2009 at 7:30 PM, John Hunter <jd...@gm...> wrote:
>>
>> On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rm...@gm...> wrote:

> Well, I checked in an example that shows the functionality.  The problem is
> that using these events doesn't follow the standard event API.  You don't
> connect using figure.canvas.mpl_connect() (it doesn't like the names
> 'xlim_changed' and 'ylim_changed'), but rather you use
> Axes.callbacks.connect().  Also, the an event object is not passed into the
> callback, but rather the originating axes instance.  Are these events relics
> to the older version of event handling that haven't been moved to the
> present?
>
> Otherwise, should I add a special section to the event handling docs to
> handle these?


Thanks for the example -- you are right that this is a 'legacy' event
callback outside the regular event framework.  So it doesn't really
belong in the event handling chapter but may merit a quick note there.
 Alternatively, we could rather easily draft up a special event
(NavigationEvent?)  that *does* work in the regular event handling
framework.  The quirk is that the events are handled at the canvas
level, so it would be difficult to register for a single axes, but one
could get a NavigationEvent if the limits of any of the axes in the
figure were updated, and use the inaxes attribute to process it.  If
this, or some variant of it, seems like a good idea I'm happy to add
it.

JDH

On Fri, Feb 13, 2009 at 6:24 AM, John Hunter <jd...@gm...> wrote:

> On Thu, Feb 12, 2009 at 2:13 PM, Ryan May <rm...@gm...> wrote:
> > On Wed, Feb 11, 2009 at 7:30 PM, John Hunter <jd...@gm...> wrote:
> >>
> >> On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rm...@gm...> wrote:
>
> > Well, I checked in an example that shows the functionality.  The problem
> is
> > that using these events doesn't follow the standard event API.  You don't
> > connect using figure.canvas.mpl_connect() (it doesn't like the names
> > 'xlim_changed' and 'ylim_changed'), but rather you use
> > Axes.callbacks.connect().  Also, the an event object is not passed into
> the
> > callback, but rather the originating axes instance.  Are these events
> relics
> > to the older version of event handling that haven't been moved to the
> > present?
> >
> > Otherwise, should I add a special section to the event handling docs to
> > handle these?
>
>
> Thanks for the example -- you are right that this is a 'legacy' event
> callback outside the regular event framework.  So it doesn't really
> belong in the event handling chapter but may merit a quick note there.
>  Alternatively, we could rather easily draft up a special event
> (NavigationEvent?)  that *does* work in the regular event handling
> framework.  The quirk is that the events are handled at the canvas
> level, so it would be difficult to register for a single axes, but one
> could get a NavigationEvent if the limits of any of the axes in the
> figure were updated, and use the inaxes attribute to process it.  If
> this, or some variant of it, seems like a good idea I'm happy to add
> it.
>

I'm +1 on your idea.  While it may be a little quirky that you can't
register for a single axes limit change, it's even weirder that you have
different ways to register for different types of events.  I think the
overall API for matplotlib is improved by bringing *all* event callbacks
under a single, unified, API.  Along those lines, I see these other 'events'
being processed in the code, but not formally recognized by the canvas level
event handler:

Aixs : 'units', 'units finalize'
Figure : 'dpi_changed'

Would it be good to try to move these to the canvas-level handler as well? I
don't have a good idea myself of how that would work right now.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

John Hunter-4 wrote:
> 
> On Thu, Feb 12, 2009 at 2:13 PM, Ryan May <rm...@gm...> wrote:
>> On Wed, Feb 11, 2009 at 7:30 PM, John Hunter <jd...@gm...> wrote:
>>>
>>> On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rm...@gm...> wrote:
> 
>> Well, I checked in an example that shows the functionality.  The problem
>> is
>> that using these events doesn't follow the standard event API.  You don't
>> connect using figure.canvas.mpl_connect() (it doesn't like the names
>> 'xlim_changed' and 'ylim_changed'), but rather you use
>> Axes.callbacks.connect().  Also, the an event object is not passed into
>> the
>> callback, but rather the originating axes instance.  Are these events
>> relics
>> to the older version of event handling that haven't been moved to the
>> present?
>>
>> Otherwise, should I add a special section to the event handling docs to
>> handle these?
> 
> 
> Thanks for the example -- you are right that this is a 'legacy' event
> callback outside the regular event framework.  So it doesn't really
> belong in the event handling chapter but may merit a quick note there.
>  Alternatively, we could rather easily draft up a special event
> (NavigationEvent?)  that *does* work in the regular event handling
> framework.  The quirk is that the events are handled at the canvas
> level, so it would be difficult to register for a single axes, but one
> could get a NavigationEvent if the limits of any of the axes in the
> figure were updated, and use the inaxes attribute to process it.  If
> this, or some variant of it, seems like a good idea I'm happy to add
> it.
> 
> JDH
> 

Hi,

Since matplotlib is about to hit 0.99, I am bringing up an old discussion
about the 'callback' events 'xlim_changed' and 'ylim_changed' which are only
available through the

callbacks.connect('xlim_changed',dostuff)

API. Is there now a way to do this through the 'standard' mpl_connect() API?
If not, would it be easy to implement this?

Thanks,

Tom

-- 
View this message in context: http://www.nabble.com/executing-function-when-view-interval-changes-tp21963695p24772257.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On 8/1/2009 4:07 PM Thomas Robitaille apparently wrote:
> Since matplotlib is about to hit 0.99, 


Which reminds me, was there a decision on subplot2grid etc?
<URL:http://sourceforge.net/mailarchive/message.php?msg_name=6e8d907b0905172009j21b5077fp242c7598ee9fb2c9%40mail.gmail.com>

Alan Isaac

On Sat, Aug 1, 2009 at 7:32 PM, Alan G Isaac<ala...@gm...> wrote:
> On 8/1/2009 4:07 PM Thomas Robitaille apparently wrote:
>> Since matplotlib is about to hit 0.99,
>
>
> Which reminds me, was there a decision on subplot2grid etc?
> <URL:http://sourceforge.net/mailarchive/message.php?msg_name=6e8d907b0905172009j21b5077fp242c7598ee9fb2c9%40mail.gmail.com>

There are lots of good suggestions in that thread -- on this issue,
all the best people will be at scipy and/or participating in the
sprint (Andrew who wrote the mpl sizer toolkit, JJ who does more
strange and wonderful things than anyone, Ryan May who has thought
through the issues and has done a lot of great work).  So we'll
definitely bring it up and see if we can do something about it.  There
are two pieces to this thread: the non-pythonic 1 based addressing of
the current subplot command ("don't blame me, talk to the mathworks"),
and the ability to easily specify column or row spans across the grid.
 The former is a minor wart that is unlikely to change, the latter is
a significant feature that we should definitely support. Maybe you can
join us via skype if not in person in  Pasadena, and we can try an
improve the current implementation.  I don't imagine adding support
for spans would be too hard,

JDH

I took a stab at this during the weekends and a patch is attached.

1) introduces a new command subplot2grid. e.g.,

subplot2grid(shape=(3,3), loc=(0,0), colspan=3)

it still creates a Subplot instance.

2) subplot command can take a SubplotSpec instance which is created
using the GridSpec.

gs = GridSpec(3,3) # shape=3,3
subplot(gs.new_subplotspec(loc=(0,0), colspan=3))

or

subplot(gs[0,:])

or

subplot(gs[0:3]) # supermongo-like

For suplot with a single cell,

subplot(gs[0])  # => subplot(331)

or

subplot(gs[0,0])


3) Each GridSpec can have associated subplot parameters (subplot
params of the figure is used if not set).


Also see the example (demo_gridspec.py).

We may further try to improve it (during the sprint maybe) if others
are happy with the patch.

Regards,

-JJ



On Sun, Aug 2, 2009 at 1:00 AM, John Hunter<jd...@gm...> wrote:
> On Sat, Aug 1, 2009 at 7:32 PM, Alan G Isaac<ala...@gm...> wrote:
>> On 8/1/2009 4:07 PM Thomas Robitaille apparently wrote:
>>> Since matplotlib is about to hit 0.99,
>>
>>
>> Which reminds me, was there a decision on subplot2grid etc?
>> <URL:http://sourceforge.net/mailarchive/message.php?msg_name=6e8d907b0905172009j21b5077fp242c7598ee9fb2c9%40mail.gmail.com>
>
> There are lots of good suggestions in that thread -- on this issue,
> all the best people will be at scipy and/or participating in the
> sprint (Andrew who wrote the mpl sizer toolkit, JJ who does more
> strange and wonderful things than anyone, Ryan May who has thought
> through the issues and has done a lot of great work).  So we'll
> definitely bring it up and see if we can do something about it.  There
> are two pieces to this thread: the non-pythonic 1 based addressing of
> the current subplot command ("don't blame me, talk to the mathworks"),
> and the ability to easily specify column or row spans across the grid.
>  The former is a minor wart that is unlikely to change, the latter is
> a significant feature that we should definitely support. Maybe you can
> join us via skype if not in person in  Pasadena, and we can try an
> improve the current implementation.  I don't imagine adding support
> for spans would be too hard,
>
> JDH
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>