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

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

···

On Wed, Feb 11, 2009 at 2:34 PM, Thomas Robitaille <thomas.robitaille@…287…> 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?


Ryan May
Graduate Research Assistant

School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

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 2:49 PM, Ryan May <rmay31@...287...> 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 ?

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

···

On Wed, Feb 11, 2009 at 7:30 PM, John Hunter <jdh2358@…287…> wrote:

On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rmay31@…287…> 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


Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Sent from: Norman Oklahoma United States.

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 Thu, Feb 12, 2009 at 2:13 PM, Ryan May <rmay31@...287...> wrote:

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

On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rmay31@...287...> 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?

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

···

On Fri, Feb 13, 2009 at 6:24 AM, John Hunter <jdh2358@…287…> wrote:

On Thu, Feb 12, 2009 at 2:13 PM, Ryan May <rmay31@…287…> wrote:

On Wed, Feb 11, 2009 at 7:30 PM, John Hunter <jdh2358@…287…> wrote:

On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rmay31@…287…> 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.


Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

John Hunter-4 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

···

On Thu, Feb 12, 2009 at 2:13 PM, Ryan May <rmay31@...287...> wrote:

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

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

--
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.

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 8/1/2009 4:07 PM Thomas Robitaille apparently wrote:

Since matplotlib is about to hit 0.99,

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

···

On Sat, Aug 1, 2009 at 7:32 PM, Alan G Isaac<alan.isaac@...287...> 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>

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

gridspec.patch (13 KB)

···

On Sun, Aug 2, 2009 at 1:00 AM, John Hunter<jdh2358@...287...> wrote:

On Sat, Aug 1, 2009 at 7:32 PM, Alan G Isaac<alan.isaac@...287...> 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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users