Before I bang my head against the wall I figured I would check the list. I have a script that uses the radio button widget in a TkAgg.=20 This worked not too long ago, but now it is not responding to clicks with the latest matplotlib. Has there been changes recently to the TkAgg backend that would affect this? Thanks - Charlie
>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes: Charlie> Before I bang my head against the wall I figured I would Charlie> check the list. I have a script that uses the radio Charlie> button widget in a TkAgg. This worked not too long ago, Charlie> but now it is not responding to clicks with the latest Charlie> matplotlib. Has there been changes recently to the TkAgg Charlie> backend that would affect this? It doesn't look like it: peds-pc311:~/mpl> svn log lib/matplotlib/backends/backend_tkagg.py ------------------------------------------------------------------------ r2139 | dsdale | 2006年03月11日 18:11:40 -0600 (2006年3月11日) | 7 lines added **kwargs to all backend_*.print_figure methods to provide papertype kwarg to backend_ps fixed landscape orientation for usetex option added subprocess module from python-2.4 ------------------------------------------------------------------------ r1889 | cmoad | 2005年11月30日 14:05:05 -0600 (2005年11月30日) | 2 lines assume png on no extension save ------------------------------------------------------------------------ r1591 | cmoad | 2005年08月08日 09:46:47 -0500 (2005年8月08日) | 2 lines almost have tkagg blitting working ------------------------------------------------------------------------ r1586 | jdh2358 | 2005年08月05日 11:13:26 -0500 (2005年8月05日) | 2 lines small cursor fix ------------------------------------------------------------------------ r1584 | cmoad | 2005年08月04日 14:13:08 -0500 (2005年8月04日) | 2 lines Added blit to FigureCanvasTkAgg, but it does not account for the bbox yet. Maybe it is a tk version problem? JDH
I shoudl have tried this in the first place. The widgets/radio_buttons.py example doesn't work at all for me. In fact quite a few are broken. buttons.py check_buttons.py radio_buttons.py sliders.py Do these work for anybody with svn? - Charlie On 3/29/06, John Hunter <jdh...@ac...> wrote: > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes: > > Charlie> Before I bang my head against the wall I figured I would > Charlie> check the list. I have a script that uses the radio > Charlie> button widget in a TkAgg. This worked not too long ago, > Charlie> but now it is not responding to clicks with the latest > Charlie> matplotlib. Has there been changes recently to the TkAgg > Charlie> backend that would affect this? > > It doesn't look like it: > > peds-pc311:~/mpl> svn log lib/matplotlib/backends/backend_tkagg.py > ------------------------------------------------------------------------ > r2139 | dsdale | 2006年03月11日 18:11:40 -0600 (2006年3月11日) | 7 > lines > > added **kwargs to all backend_*.print_figure > methods to provide papertype kwarg to backend_ps > > fixed landscape orientation for usetex option > > added subprocess module from python-2.4 > > ------------------------------------------------------------------------ > r1889 | cmoad | 2005年11月30日 14:05:05 -0600 (2005年11月30日) | 2 lines > > assume png on no extension save > > ------------------------------------------------------------------------ > r1591 | cmoad | 2005年08月08日 09:46:47 -0500 (2005年8月08日) | 2 lines > > almost have tkagg blitting working > > ------------------------------------------------------------------------ > r1586 | jdh2358 | 2005年08月05日 11:13:26 -0500 (2005年8月05日) | 2 > lines > > small cursor fix > > ------------------------------------------------------------------------ > r1584 | cmoad | 2005年08月04日 14:13:08 -0500 (2005年8月04日) | 2 lines > > Added blit to FigureCanvasTkAgg, but it does not account for the bbox > yet. > > > > Maybe it is a tk version problem? > > JDH >
Charlie Moad wrote: > I shoudl have tried this in the first place. The > widgets/radio_buttons.py example doesn't work at all for me. In fact > quite a few are broken. > > buttons.py > check_buttons.py > radio_buttons.py > sliders.py > > Do these work for anybody with svn? They don't work for me with GtkAgg, so it is not a Tk-specific backend problem. I hope it is not something I have broken... I have never looked at or tested the widgets before. Eric > > - Charlie > > On 3/29/06, John Hunter <jdh...@ac...> wrote: > >>>>>>>"Charlie" == Charlie Moad <cw...@gm...> writes: >> >> Charlie> Before I bang my head against the wall I figured I would >> Charlie> check the list. I have a script that uses the radio >> Charlie> button widget in a TkAgg. This worked not too long ago, >> Charlie> but now it is not responding to clicks with the latest >> Charlie> matplotlib. Has there been changes recently to the TkAgg >> Charlie> backend that would affect this? >> >>It doesn't look like it: >> >>peds-pc311:~/mpl> svn log lib/matplotlib/backends/backend_tkagg.py >>------------------------------------------------------------------------ >>r2139 | dsdale | 2006年03月11日 18:11:40 -0600 (2006年3月11日) | 7 >>lines >> >>added **kwargs to all backend_*.print_figure >>methods to provide papertype kwarg to backend_ps >> >>fixed landscape orientation for usetex option >> >>added subprocess module from python-2.4 >> >>------------------------------------------------------------------------ >>r1889 | cmoad | 2005年11月30日 14:05:05 -0600 (2005年11月30日) | 2 lines >> >>assume png on no extension save >> >>------------------------------------------------------------------------ >>r1591 | cmoad | 2005年08月08日 09:46:47 -0500 (2005年8月08日) | 2 lines >> >>almost have tkagg blitting working >> >>------------------------------------------------------------------------ >>r1586 | jdh2358 | 2005年08月05日 11:13:26 -0500 (2005年8月05日) | 2 >>lines >> >>small cursor fix >> >>------------------------------------------------------------------------ >>r1584 | cmoad | 2005年08月04日 14:13:08 -0500 (2005年8月04日) | 2 lines >> >>Added blit to FigureCanvasTkAgg, but it does not account for the bbox >>yet. >> >> >> >>Maybe it is a tk version problem? >> >>JDH >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid1720ドル&dat1642 > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> I hope it is not something I have broken... Eric> I have never looked at or tested the widgets before. It looks like mouse event handling is being swallowed. It looks like I'm not getting x-y cursor updates in the toolbar. Looking at the CHANGELOG, I suspect 2006年03月17日 Applied sophana's patch to support overlapping axes with toolbar navigation by toggling activation with the 'a' key. Closes sf patch 1432252 - JDH And indeed, when I press 'a', the event handling comes back. The odd thing is that Axes.__init__ is calling self.set_navigate(True) (which is what 'a' does in backend_bases.FigureManagerBase.key_press. So I'm confused, but at least we are on the scent. JDH
>>>>> "John" == John Hunter <jdh...@ac...> writes: John> It looks like mouse event handling is being swallowed. It John> looks like I'm not getting x-y cursor updates in the John> toolbar. All this was due to an X11 lag, so it can mostly be ignore. Back into the dark... JDH
>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes: Charlie> I shoudl have tried this in the first place. The Charlie> widgets/radio_buttons.py example doesn't work at all for Charlie> me. In fact quite a few are broken. I noticed today that the subplots_adjust toolbar widget is broken too... So this is a fairly high priority bug. JDH
On 3/31/06, John Hunter <jdh...@ac...> wrote: > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes: > > Charlie> I shoudl have tried this in the first place. The > Charlie> widgets/radio_buttons.py example doesn't work at all for > Charlie> me. In fact quite a few are broken. > > I noticed today that the subplots_adjust toolbar widget is broken > too... So this is a fairly high priority bug. I dug this one up and it is a one line fix. Line 670 backend_bases.py: LocationEvent.__init__ < if self.x is not None and self.y is not None and a.in_axes(self.x, self.y) and a.get_navigate(): > if self.x is not None and self.y is not None and a.in_axes(self.x, self.y= ): From what I can gather, the _nagivate property means an axes should not respond to adjusting events from the nav toolbar. Therefore, it seems incorrect to assume that an axes that does not want to navigate cannot have mouse/key interactions. The widgets are an example of this case. John, you added this logic with comment, "added support for multiple overlapping axes with pan/zoom". I think for a user to address this problem correctly they should use the zorder property. I added a check a while back that sets the inaxes property of a LocationEvent to the highest zorder if multiple axes are found. Fixed in svn. - Charlie
>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes: Charlie> John, you added this logic with comment, "added support Charlie> for multiple overlapping axes with pan/zoom". I think This was a user contributed patch, but I did check it in. Charlie> for a user to address this problem correctly they should Charlie> use the zorder property. I added a check a while back Charlie> that sets the inaxes property of a LocationEvent to the Charlie> highest zorder if multiple axes are found. It's a little more than zorder, though, since in the case of examples/two_scales.py you have to axes that entirely overlap one another, and you may want both to respond to navigation. In general I like the idea of using zorder to determine which axes responds to navigation commands, but do you think it can handle this case as well. Charlie> Fixed in svn. Thanks for looking into this one. JDH
> It's a little more than zorder, though, since in the case of > examples/two_scales.py you have to axes that entirely overlap one > another, and you may want both to respond to navigation. In general I > like the idea of using zorder to determine which axes responds to > navigation commands, but do you think it can handle this case as well. In this case I think the correct approach would be to set the zorder higher on one axes, and in that axes' callback programmatically invoke the same event for the other axes. I will look at the example and implement/comment this approach. - Charlie
On 4/3/06, Charlie Moad <cw...@gm...> wrote: > > It's a little more than zorder, though, since in the case of > > examples/two_scales.py you have to axes that entirely overlap one > > another, and you may want both to respond to navigation. In general I > > like the idea of using zorder to determine which axes responds to > > navigation commands, but do you think it can handle this case as well. I wasn't aware of the pylab twinx function which is what broke. The nav-toolbar events still work for me. The subplots adjust functionality broke though. I fixed this by accounting for the case that _sharex or _sharey is an instance of Subplot. I didn't modify two_scales.py at all and everything seems to be working correctly. In the case you want custom key or mouse event interaction in two_scales, one might have to do the zorder trick I mentioned before.=20 Committed. The broken subplots toolbar might justify a minor release here soon, unless you think it can wait until 88. Since no one has complained (except me), it might be able to wait. - Charlie
>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes: Charlie> In this case I think the correct approach would be to set Charlie> the zorder higher on one axes, and in that axes' callback Charlie> programmatically invoke the same event for the other Charlie> axes. I will look at the example and implement/comment Charlie> this approach. I don't feel strongly about this, but since the patch I applied does set a navigation toggle flag, is it not preferable to simply fix the logic error and allow the user to set this flag rather than have to set a callback? JDH
On 4/3/06, John Hunter <jdh...@ac...> wrote: > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes: > > Charlie> In this case I think the correct approach would be to set > Charlie> the zorder higher on one axes, and in that axes' callback > Charlie> programmatically invoke the same event for the other > Charlie> axes. I will look at the example and implement/comment > Charlie> this approach. > > I don't feel strongly about this, but since the patch I applied does > set a navigation toggle flag, is it not preferable to simply fix the > logic error and allow the user to set this flag rather than have to > set a callback? I don't know if you saw my latest post before writing this. Please try two_scales with the latest and I believe it is satisfactory now.
>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes: Charlie> I don't know if you saw my latest post before writing Charlie> this. Please try two_scales with the latest and I Charlie> believe it is satisfactory now. No, I sent my post before reading your last, but the two_scales example is acting weird. When I zoom-to-rect, the zoom does not go to the rectangle I choose. JDH
On 4/3/06, John Hunter <jdh...@ac...> wrote: > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes: > > Charlie> I don't know if you saw my latest post before writing > Charlie> this. Please try two_scales with the latest and I > Charlie> believe it is satisfactory now. > > > No, I sent my post before reading your last, but the two_scales > example is acting weird. When I zoom-to-rect, the zoom does not go to > the rectangle I choose. From what I am seeing the x axis is zooming too much, but the y axis is fine. I am guessing this has something to do with the shared axis being acted on twice. Indeed the release_zoom method of NavTB2 is being called twice. Any ideas on how to handle this? The limits need to be adjusted on both plots still, but somehow we need to know to only adjust the shared axis once. - Charlie