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.htmlShould 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:
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
matplotlib-users List Signup and Options