You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Olivier B. <Oli...@id...> - 2005-04-14 14:19:43
|
Hello all, I'm converting some matlab scripts to matlibplot, and I don't know how to make some "slicing" efficently with matlibplot. What I want to do is to translate a matlab code like: x =3D [[01, 02, 03, 04, 05, 06]; [11, 12, 13, 14, 15, 16]; [21, 22, 23, 24, 25, 26]; [31, 32, 33, 34, 35, 36]; [41, 42, 43, 44, 45, 46]; [51, 52, 53, 54, 55, 56] ]; x(2:4,1:4) =20 ans =3D =20 11 12 13 14 21 22 23 24 31 32 33 34 =20 What I have done now in matplotlib is like: x =3D array ([[01, 02, 03, 04, 05, 06], [11, 12, 13, 14, 15, 16], [21, 22, 23, 24, 25, 26], [31, 32, 33, 34, 35, 36], [41, 42, 43, 44, 45, 46], [51, 52, 53, 54, 55, 56], ]) for i in range (3): for j in range (4): x2 [i][j] =3D x [i+1][j+0] so, x2 is now what I want: [[11,12,13,14,] [21,22,23,24,] [31,32,33,34,]] I will be very happy to make the "slicing" without the loop... I'm pretty new to matlibplot, so sorry if this is a too simple question. Thanks in advance for your help. Olivier --=20 . __ . ___ __. | Olivier Bornet Oli...@id... / / ` / / / / / | IDIAP http://www.idiap.ch/~bornet/ / / / / /--/ /--' | CP 592 http://www.idiap.ch/~bornet/pgp/ / /__.' / / / / | CH-1920 Martigny PGP-key: 0xC53D9218 |
From: Werner F. B. <wer...@fr...> - 2005-04-14 12:36:16
|
Hi All, The legend lables etc I pass to matplotlib contain things like "äü" (i.e. European character set) but they don't get displayed in the plots. Is there something special one needs to do to support this? Using wxPython 2.5.5.1 ANSI build (can't switch to Unicode just yet) on Windows (XP, 2000). See you Werner |
From: Sascha S. <sc...@te...> - 2005-04-14 11:17:07
|
Am Thu, 14 Apr 2005 21:02:09 +1000 hast Du, Robert Leftwich <robert@leftw= ich.info>, mir dies geschrieben: > Sascha Schnepp wrote: >> >> I already posted this some days ago to the list but I'm still hoping f= or >> answers... >> >> I don't like the blackedge of the marker symbols very much. Therefore = I >> changed the markeredgewidth to zero. But this isn't the appropriate >> solution because it makes the markers + and x vanish. Is there a >> possibilty for the markeredge to inherit its color from the marker sym= bol? >> > > I'm not sure of your scenario, but you can specify that the marker edge= and face > colour are the same when calling the axes.plot() function, e.g. > > defaultMarkerColor =3D 'b' > ax.plot(sx, sy, linestyle=3D'None', markersize=3DdefaultMarkerSize, = marker=3D'v', > zorder=3D'1', markerfacecolor=3DdefaultMarkerColor, markeredgecolor=3Dd= efaultMarkerColor) That helped! Thank you! I often don't know which attributes can be used as kwargs... Greetings, Sascha > > Note also that a line has a function set_markeredgecolor() where you ca= n set the > edge colour. > > HTH > > Robert > --=20 -------------------------------------------------------------------------= -- Sascha Schnepp Institut f=FCr Theorie Elektromagnetischer Felder (TEMF) TU Darms= tadt Fachbereich Elektrotechnik und Informationstechnik Schlo=DFgartenstra=DFe 8 / D 64289 Darmstadt phone: +49 (0)6151 1= 6-2261 mailto:sc...@te... fax: +49 (0)6151 16-46= 11 http://www.temf.de PGP-Key: 0xF660E207 (04/15/05) Three o'clock is always too late or too early for anything you want to do. -- Jean-Paul Sartre -------------------------------------------------------------------------= -- |
From: Robert L. <ro...@le...> - 2005-04-14 11:02:24
|
Sascha Schnepp wrote: > > I already posted this some days ago to the list but I'm still hoping for > answers... > > I don't like the blackedge of the marker symbols very much. Therefore I > changed the markeredgewidth to zero. But this isn't the appropriate > solution because it makes the markers + and x vanish. Is there a > possibilty for the markeredge to inherit its color from the marker symbol? > I'm not sure of your scenario, but you can specify that the marker edge and face colour are the same when calling the axes.plot() function, e.g. defaultMarkerColor = 'b' ax.plot(sx, sy, linestyle='None', markersize=defaultMarkerSize, marker='v', zorder='1', markerfacecolor=defaultMarkerColor, markeredgecolor=defaultMarkerColor) Note also that a line has a function set_markeredgecolor() where you can set the edge colour. HTH Robert |
From: Sascha S. <sc...@te...> - 2005-04-14 10:42:51
|
Hi, I already posted this some days ago to the list but I'm still hoping for = answers... I don't like the blackedge of the marker symbols very much. Therefore I c= hanged the markeredgewidth to zero. But this isn't the appropriate soluti= on because it makes the markers + and x vanish. Is there a possibilty for= the markeredge to inherit its color from the marker symbol? Thanks a lot, Sascha |
From: John G. <jn...@eu...> - 2005-04-14 09:59:09
|
For gtk you can use something like this: keyvald = {} for name in ['Up', 'Down', 'Left', 'Right']: keyvald[name.lower()] = gtk.gdk.keyval_from_name(name) John Tim Leslie wrote: > On Wed, 13 Apr 2005, Werner F. Bruhin <wer...@fr...> wrote... > > > Hi Tim and John, > > > > I didn't catch on to this earlier but shouldn't the backend_wx.py use > > something along these lines: > > > > keyvald = {wx.WXK_CONTROL : 'control', > > wx.WXK_SHIFT : 'shift', > > wx.WXK_ALT : 'alt', > > wx.WXK_LEFT : 'left', > > wx.WXK_UP : 'up', > > wx.WXK_RIGHT : 'right', > > wx.WXK_DOWN : 'down', > > } > > > > For more WXK codes see the wx demo Process and Events/KeyEvents. > > I suppose that would be the sane thing to do, yes. Presumably we can also > find similar codes for GTK. I'll have a look for them today. > > Tim > > > > > See you > > Werner > > > > > > Tim Leslie wrote: > > >OK, here are the diffs for each backend: > > > > > >~/src/matplotlib-0.80/lib/matplotlib/backends/backend_gtk.py > > >109,112d108 > > >< 65361 : 'left', > > >< 65362 : 'up', > > >< 65363 : 'right', > > >< 65364 : 'down', > > > > > >~/src/matplotlib-0.80/lib/matplotlib/backends/backend_wx.py > > >675,678d674 > > >< 316 : 'left', > > >< 317 : 'up', > > >< 318 : 'right', > > >< 319 : 'down', > > > > > >~/src/matplotlib-0.80/lib/matplotlib/backends/backend_tkagg.py > > >99,102d98 > > >< 65361 : 'left', > > >< 65362 : 'up', > > >< 65363 : 'right', > > >< 65364 : 'down', > > > > > >~/src/matplotlib-0.80/lib/matplotlib/backends/backend_qt.py > > >74,77d73 > > >< qt.Qt.Key_Left : 'left', > > >< qt.Qt.Key_Up : 'up', > > >< qt.Qt.Key_Right : 'right', > > >< qt.Qt.Key_Down : 'down', > > > > > >As you can see, it's reasonably straightforward to add these extra > keys, > > >so if anyone feels creative and wants other keys added, this should > give > > >an idea of what needs changing. > > > > > >As for my problem with gtk and the down key, I've rebuilt pygtk > (2.6.1), > > >installed matplotlib 0.80, and the problem is still there. I > whipped up a > > >trivial pygtk program which was a window which connected to key press > > >events and it worked just fine, so it seems that there's something > that > > >matplotlib is doing which triggers the bug (that's not to say the > bug is > > >in mpl of course). I'm guessing there is something in my system setup > > >which is flakey and causing it to happen, but it's 3am and I'm > tired so > > >I'll just live with it for now :) > > > > > >Cheers, > > > > > >Tim Leslie > > > > > >On Thu, 14 Apr 2005, Tim Leslie <ti...@cs...> wrote... > > > > > > > > >>Just to follow up on this, I made the required changes to the other > > >>backends and they worked fine. GTK and GTKAgg had the same broken > > >>behaviour while TkAgg, WX and WXAgg worked fine (don't have qt > installed). > > >> > > >>I'll bring all my libraries up to date (thanks for 0.80 tonight) > and dive > > >>into the pygtk stuff a bit deeper to see if I can find out what's > > >>breaking. > > >> > > >>Having looked through a bit more mpl code I'd just like to say > that I'm > > >>very impressed with how simple it is to read. After working out > what to > > >>change in GTK, it followed an identical pattern in the other backends > > >>which was very nice to see. > > >> > > >>Cheers, > > >> > > >>Tim Leslie > > >> > > >>On Thu, 14 Apr 2005, Tim Leslie <ti...@cs...> wrote... > > >> > > >> > > >>>On Wed, 13 Apr 2005, John Hunter <jdh...@ac...> > wrote... > > >>> > > >>> > > >>>>>>>>>"Tim" == Tim Leslie <ti...@cs...> writes: > > >>>> > > >>>> Tim> This all works fine except that the down key doesn't > register > > >>>> Tim> as released. After registering the down key press, no > other > > >>>> Tim> key events register until you hit the up key, at which > point > > >>>> Tim> the key release triggers for the up. > > >>>> > > >>>>It works fine for me -- what is your pygtk version and OS? > > >>>>I'm using pygtk 2.2.0 on linux. > > >>> > > >>>AFAICT pygtk 2.0, this is running on ubuntu unstable. > > >>> > > >>> > > >>>>You might put some debug print statements to print event.keyval in > > >>>>_get_key to see if an event is being triggered at the gtk level. > > >>> > > >>>OK, I'll have a play with that. > > >>> > > >>> > > >>>>Could it be a bad keyboard??? > > >>> > > >>>Yep :) Well, maybe. The down key works in every other app I use, > but I've > > >>>had problems with this keyboard in strange ways before, so I > wouldn't put > > >>>it past it. I'll try it out on another machine when I get a > chance and > > >>>see > > >>>how it goes. It's a laptop, so I can't really change the > keyboard. (hmm, > > >>>maybe a usb external one, if I had one) > > >>> > > >>> > > >>>> Tim> I really don't know a lot about Gtk or the matplotlib > > >>>> Tim> internals so I couldn't trace this bug deeper into the > > >>>> Tim> libraries. Can anyone shed some light on what's going > on? If > > >>>> Tim> we can get the arrow keys working is there a chance of > > >>>> Tim> getting them into the standard distribution (assuming we > had > > >>>> Tim> all backends working)? > > >>>> > > >>>>Absolutely. It might be nice to enable some standard keyboard > > >>>>navigation too. > > >>> > > >>>OK well I'll play around with this some more and I'll get back to > you > > >>>once > > >>>I have what I think is a complete, working patch. > > >>> > > >>>Cheers, > > >>> > > >>>Tim Leslie > > >>> > > >>> > > >>>>JDH > > >>>> > > >>> > > >>>`- > > >>> > > >>> > > >>>------------------------------------------------------- > > >>>SF email is sponsored by - The IT Product Guide > > >>>Read honest & candid reviews on hundreds of IT Products from real > users. > > >>>Discover which products truly live up to the hype. Start reading > now. > > >>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click> > > >>>_______________________________________________ > > >>>Matplotlib-users mailing list > > >>>Mat...@li... > > >>>https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > >>> > > >> > > >>`- > > >> > > >> > > >>------------------------------------------------------- > > >>SF email is sponsored by - The IT Product Guide > > >>Read honest & candid reviews on hundreds of IT Products from real > users. > > >>Discover which products truly live up to the hype. Start reading now. > > >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click> > > >>_______________________________________________ > > >>Matplotlib-users mailing list > > >>Mat...@li... > > >>https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > >> > > > > > >`- > > > > > > > > >------------------------------------------------------- > > >SF email is sponsored by - The IT Product Guide > > >Read honest & candid reviews on hundreds of IT Products from real > users. > > >Discover which products truly live up to the hype. Start reading now. > > >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click> > > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real > users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click> > > _______________________________________________ > > Matplotlib-users mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > `- > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click> > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > |
From: Werner F. B. <wer...@fr...> - 2005-04-14 09:43:53
|
Hi All, Doing multiple plots I see that memory usage grows and grows. Before doing a new plot I do "self.figure.clear()", or "self.figure.clf()", is there some other call I should use? See you Werner |
From: John H. <jdh...@ac...> - 2005-04-14 03:16:35
|
>>>>> "Michael" == Michael Brady <mb...@jp...> writes: Michael> I tried setting the z-order of the tick objects, but it Michael> looks to me like the ticks are hard-coded to always draw Michael> before (underneath) any lines or patches. That's right, they are. This is a bug and not a feature :-( The ticks are drawn as part of the Axis. See matplotlib.axes.Axes.draw, eg if self.axison: self.xaxis.draw(renderer) self.yaxis.draw(renderer) The Axis instances (XAxis and YAxis) are comprised of Line2D (the ticks) and Text (the labels) instances. Michael> Is there a way to tell the Axes to draw the ticks on top Michael> of any Polygons instead of underneath? As noted above, before any of the zorder sorting is done, the xaxis and yaxis are drawn. One possible solution is to move the axis drawing commands to the end of the Axes.draw function. Off the top of my head, I don't see any problem with this approach. Typically, you want the ticks visible. We've talked in the past on the dev list about the desirability in supporting ticking inside, center or outside the axes box, but it hasn't been implemented yet. Vis-a-vis zorder sorting, a more general solution would be to have a method which extracts the Artist primitives (Line2D and Text) from the XAxis and YAxis and adds them to the sort, but I'm not sure if this is actually better. In real life, I think you always want them on top. Right? Michael> If not, it doesn't look like it would be too hard to Michael> modify Axes.draw() to respect the z-order of ticks. I'm Michael> happy to do this, although I'm nervous that it might Michael> break stuff that assumes that ticks are always drawn Michael> before everything else. John, do you recommend that I Michael> create such a mod? Yes, if you can find something that works, and behaves sanely over the poorman's unit tests in examples/backend_driver.py. JDH |
From: Tim L. <ti...@cs...> - 2005-04-14 01:06:11
|
On Wed, 13 Apr 2005, Werner F. Bruhin <wer...@fr...> wrote... > Hi Tim and John, > > I didn't catch on to this earlier but shouldn't the backend_wx.py use > something along these lines: > > keyvald = {wx.WXK_CONTROL : 'control', > wx.WXK_SHIFT : 'shift', > wx.WXK_ALT : 'alt', > wx.WXK_LEFT : 'left', > wx.WXK_UP : 'up', > wx.WXK_RIGHT : 'right', > wx.WXK_DOWN : 'down', > } > > For more WXK codes see the wx demo Process and Events/KeyEvents. I suppose that would be the sane thing to do, yes. Presumably we can also find similar codes for GTK. I'll have a look for them today. Tim > > See you > Werner > > > Tim Leslie wrote: > >OK, here are the diffs for each backend: > > > >~/src/matplotlib-0.80/lib/matplotlib/backends/backend_gtk.py > >109,112d108 > >< 65361 : 'left', > >< 65362 : 'up', > >< 65363 : 'right', > >< 65364 : 'down', > > > >~/src/matplotlib-0.80/lib/matplotlib/backends/backend_wx.py > >675,678d674 > >< 316 : 'left', > >< 317 : 'up', > >< 318 : 'right', > >< 319 : 'down', > > > >~/src/matplotlib-0.80/lib/matplotlib/backends/backend_tkagg.py > >99,102d98 > >< 65361 : 'left', > >< 65362 : 'up', > >< 65363 : 'right', > >< 65364 : 'down', > > > >~/src/matplotlib-0.80/lib/matplotlib/backends/backend_qt.py > >74,77d73 > >< qt.Qt.Key_Left : 'left', > >< qt.Qt.Key_Up : 'up', > >< qt.Qt.Key_Right : 'right', > >< qt.Qt.Key_Down : 'down', > > > >As you can see, it's reasonably straightforward to add these extra keys, > >so if anyone feels creative and wants other keys added, this should give > >an idea of what needs changing. > > > >As for my problem with gtk and the down key, I've rebuilt pygtk (2.6.1), > >installed matplotlib 0.80, and the problem is still there. I whipped up a > >trivial pygtk program which was a window which connected to key press > >events and it worked just fine, so it seems that there's something that > >matplotlib is doing which triggers the bug (that's not to say the bug is > >in mpl of course). I'm guessing there is something in my system setup > >which is flakey and causing it to happen, but it's 3am and I'm tired so > >I'll just live with it for now :) > > > >Cheers, > > > >Tim Leslie > > > >On Thu, 14 Apr 2005, Tim Leslie <ti...@cs...> wrote... > > > > > >>Just to follow up on this, I made the required changes to the other > >>backends and they worked fine. GTK and GTKAgg had the same broken > >>behaviour while TkAgg, WX and WXAgg worked fine (don't have qt installed). > >> > >>I'll bring all my libraries up to date (thanks for 0.80 tonight) and dive > >>into the pygtk stuff a bit deeper to see if I can find out what's > >>breaking. > >> > >>Having looked through a bit more mpl code I'd just like to say that I'm > >>very impressed with how simple it is to read. After working out what to > >>change in GTK, it followed an identical pattern in the other backends > >>which was very nice to see. > >> > >>Cheers, > >> > >>Tim Leslie > >> > >>On Thu, 14 Apr 2005, Tim Leslie <ti...@cs...> wrote... > >> > >> > >>>On Wed, 13 Apr 2005, John Hunter <jdh...@ac...> wrote... > >>> > >>> > >>>>>>>>>"Tim" == Tim Leslie <ti...@cs...> writes: > >>>> > >>>> Tim> This all works fine except that the down key doesn't register > >>>> Tim> as released. After registering the down key press, no other > >>>> Tim> key events register until you hit the up key, at which point > >>>> Tim> the key release triggers for the up. > >>>> > >>>>It works fine for me -- what is your pygtk version and OS? > >>>>I'm using pygtk 2.2.0 on linux. > >>> > >>>AFAICT pygtk 2.0, this is running on ubuntu unstable. > >>> > >>> > >>>>You might put some debug print statements to print event.keyval in > >>>>_get_key to see if an event is being triggered at the gtk level. > >>> > >>>OK, I'll have a play with that. > >>> > >>> > >>>>Could it be a bad keyboard??? > >>> > >>>Yep :) Well, maybe. The down key works in every other app I use, but I've > >>>had problems with this keyboard in strange ways before, so I wouldn't put > >>>it past it. I'll try it out on another machine when I get a chance and > >>>see > >>>how it goes. It's a laptop, so I can't really change the keyboard. (hmm, > >>>maybe a usb external one, if I had one) > >>> > >>> > >>>> Tim> I really don't know a lot about Gtk or the matplotlib > >>>> Tim> internals so I couldn't trace this bug deeper into the > >>>> Tim> libraries. Can anyone shed some light on what's going on? If > >>>> Tim> we can get the arrow keys working is there a chance of > >>>> Tim> getting them into the standard distribution (assuming we had > >>>> Tim> all backends working)? > >>>> > >>>>Absolutely. It might be nice to enable some standard keyboard > >>>>navigation too. > >>> > >>>OK well I'll play around with this some more and I'll get back to you > >>>once > >>>I have what I think is a complete, working patch. > >>> > >>>Cheers, > >>> > >>>Tim Leslie > >>> > >>> > >>>>JDH > >>>> > >>> > >>>`- > >>> > >>> > >>>------------------------------------------------------- > >>>SF email is sponsored by - The IT Product Guide > >>>Read honest & candid reviews on hundreds of IT Products from real users. > >>>Discover which products truly live up to the hype. Start reading now. > >>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >>>_______________________________________________ > >>>Matplotlib-users mailing list > >>>Mat...@li... > >>>https://lists.sourceforge.net/lists/listinfo/matplotlib-users > >>> > >> > >>`- > >> > >> > >>------------------------------------------------------- > >>SF email is sponsored by - The IT Product Guide > >>Read honest & candid reviews on hundreds of IT Products from real users. > >>Discover which products truly live up to the hype. Start reading now. > >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >>_______________________________________________ > >>Matplotlib-users mailing list > >>Mat...@li... > >>https://lists.sourceforge.net/lists/listinfo/matplotlib-users > >> > > > >`- > > > > > >------------------------------------------------------- > >SF email is sponsored by - The IT Product Guide > >Read honest & candid reviews on hundreds of IT Products from real users. > >Discover which products truly live up to the hype. Start reading now. > >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > `- |
From: Michael B. <mb...@jp...> - 2005-04-13 23:19:13
|
While using Basemap, I've come across a small problem. The Basemap fillcontinents() function creates Polygon objects and adds them to the Axes. These Polygons always seem to cover up the Axes ticks. I tried setting the z-order of the tick objects, but it looks to me like the ticks are hard-coded to always draw before (underneath) any lines or patches. Is there a way to tell the Axes to draw the ticks on top of any Polygons instead of underneath? If not, it doesn't look like it would be too hard to modify Axes.draw() to respect the z-order of ticks. I'm happy to do this, although I'm nervous that it might break stuff that assumes that ticks are always drawn before everything else. John, do you recommend that I create such a mod? Thanks for any help, Michael ======================================================================== Michael Brady Jet Propulsion Laboratory (M/S 301-140L) 4800 Oak Grove Drive Pasadena, CA 91109 ======================================================================== |
From: Werner F. B. <wer...@fr...> - 2005-04-13 18:51:20
|
Hi Tim and John, I didn't catch on to this earlier but shouldn't the backend_wx.py use something along these lines: keyvald = {wx.WXK_CONTROL : 'control', wx.WXK_SHIFT : 'shift', wx.WXK_ALT : 'alt', wx.WXK_LEFT : 'left', wx.WXK_UP : 'up', wx.WXK_RIGHT : 'right', wx.WXK_DOWN : 'down', } For more WXK codes see the wx demo Process and Events/KeyEvents. See you Werner Tim Leslie wrote: > OK, here are the diffs for each backend: > > ~/src/matplotlib-0.80/lib/matplotlib/backends/backend_gtk.py > 109,112d108 > < 65361 : 'left', > < 65362 : 'up', > < 65363 : 'right', > < 65364 : 'down', > > ~/src/matplotlib-0.80/lib/matplotlib/backends/backend_wx.py > 675,678d674 > < 316 : 'left', > < 317 : 'up', > < 318 : 'right', > < 319 : 'down', > > ~/src/matplotlib-0.80/lib/matplotlib/backends/backend_tkagg.py > 99,102d98 > < 65361 : 'left', > < 65362 : 'up', > < 65363 : 'right', > < 65364 : 'down', > > ~/src/matplotlib-0.80/lib/matplotlib/backends/backend_qt.py > 74,77d73 > < qt.Qt.Key_Left : 'left', > < qt.Qt.Key_Up : 'up', > < qt.Qt.Key_Right : 'right', > < qt.Qt.Key_Down : 'down', > > As you can see, it's reasonably straightforward to add these extra keys, > so if anyone feels creative and wants other keys added, this should give > an idea of what needs changing. > > As for my problem with gtk and the down key, I've rebuilt pygtk (2.6.1), > installed matplotlib 0.80, and the problem is still there. I whipped up a > trivial pygtk program which was a window which connected to key press > events and it worked just fine, so it seems that there's something that > matplotlib is doing which triggers the bug (that's not to say the bug is > in mpl of course). I'm guessing there is something in my system setup > which is flakey and causing it to happen, but it's 3am and I'm tired so > I'll just live with it for now :) > > Cheers, > > Tim Leslie > > On Thu, 14 Apr 2005, Tim Leslie <ti...@cs...> wrote... > > >>Just to follow up on this, I made the required changes to the other >>backends and they worked fine. GTK and GTKAgg had the same broken >>behaviour while TkAgg, WX and WXAgg worked fine (don't have qt installed). >> >>I'll bring all my libraries up to date (thanks for 0.80 tonight) and dive >>into the pygtk stuff a bit deeper to see if I can find out what's >>breaking. >> >>Having looked through a bit more mpl code I'd just like to say that I'm >>very impressed with how simple it is to read. After working out what to >>change in GTK, it followed an identical pattern in the other backends >>which was very nice to see. >> >>Cheers, >> >>Tim Leslie >> >>On Thu, 14 Apr 2005, Tim Leslie <ti...@cs...> wrote... >> >> >>>On Wed, 13 Apr 2005, John Hunter <jdh...@ac...> wrote... >>> >>> >>>>>>>>>"Tim" == Tim Leslie <ti...@cs...> writes: >>>> >>>> Tim> This all works fine except that the down key doesn't register >>>> Tim> as released. After registering the down key press, no other >>>> Tim> key events register until you hit the up key, at which point >>>> Tim> the key release triggers for the up. >>>> >>>>It works fine for me -- what is your pygtk version and OS? >>>>I'm using pygtk 2.2.0 on linux. >>> >>>AFAICT pygtk 2.0, this is running on ubuntu unstable. >>> >>> >>>>You might put some debug print statements to print event.keyval in >>>>_get_key to see if an event is being triggered at the gtk level. >>> >>>OK, I'll have a play with that. >>> >>> >>>>Could it be a bad keyboard??? >>> >>>Yep :) Well, maybe. The down key works in every other app I use, but I've >>>had problems with this keyboard in strange ways before, so I wouldn't put >>>it past it. I'll try it out on another machine when I get a chance and see >>>how it goes. It's a laptop, so I can't really change the keyboard. (hmm, >>>maybe a usb external one, if I had one) >>> >>> >>>> Tim> I really don't know a lot about Gtk or the matplotlib >>>> Tim> internals so I couldn't trace this bug deeper into the >>>> Tim> libraries. Can anyone shed some light on what's going on? If >>>> Tim> we can get the arrow keys working is there a chance of >>>> Tim> getting them into the standard distribution (assuming we had >>>> Tim> all backends working)? >>>> >>>>Absolutely. It might be nice to enable some standard keyboard >>>>navigation too. >>> >>>OK well I'll play around with this some more and I'll get back to you once >>>I have what I think is a complete, working patch. >>> >>>Cheers, >>> >>>Tim Leslie >>> >>> >>>>JDH >>>> >>> >>>`- >>> >>> >>>------------------------------------------------------- >>>SF email is sponsored by - The IT Product Guide >>>Read honest & candid reviews on hundreds of IT Products from real users. >>>Discover which products truly live up to the hype. Start reading now. >>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>>_______________________________________________ >>>Matplotlib-users mailing list >>>Mat...@li... >>>https://lists.sourceforge.net/lists/listinfo/matplotlib-users >>> >> >>`- >> >> >>------------------------------------------------------- >>SF email is sponsored by - The IT Product Guide >>Read honest & candid reviews on hundreds of IT Products from real users. >>Discover which products truly live up to the hype. Start reading now. >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>_______________________________________________ >>Matplotlib-users mailing list >>Mat...@li... >>https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> > > `- > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click |
From: John H. <jdh...@ac...> - 2005-04-13 18:23:35
|
>>>>> "Tim" == Tim Leslie <ti...@cs...> writes: Tim> OK, here are the diffs for each backend: OK, I added these to my local tree. Thanks for tracking these down across backends. Now if Gregory or someone can just get these for fltk, we'll be done. Tim> As for my problem with gtk and the down key, I've rebuilt Tim> pygtk (2.6.1), installed matplotlib 0.80, and the problem is Tim> still there. I whipped up a trivial pygtk program which was a Tim> window which connected to key press events and it worked just Tim> fine, so it seems that there's something that matplotlib is Tim> doing which triggers the bug (that's not to say the bug is in Tim> mpl of course). I'm guessing there is something in my system Tim> setup which is flakey and causing it to happen, but it's 3am Tim> and I'm tired so I'll just live with it for now :) I have seen on some GUIs that different keyvals are sent for the same key, so do check and see what event.keyval is reporting; you may need to add additional dictionary entries to keyvald. I also tried to replicate the problem on pygtk-2.0.0 on win32, but down-arrow press and release worked as they should. JDH |
From: Tim L. <ti...@cs...> - 2005-04-13 16:49:31
|
OK, here are the diffs for each backend: ~/src/matplotlib-0.80/lib/matplotlib/backends/backend_gtk.py 109,112d108 < 65361 : 'left', < 65362 : 'up', < 65363 : 'right', < 65364 : 'down', ~/src/matplotlib-0.80/lib/matplotlib/backends/backend_wx.py 675,678d674 < 316 : 'left', < 317 : 'up', < 318 : 'right', < 319 : 'down', ~/src/matplotlib-0.80/lib/matplotlib/backends/backend_tkagg.py 99,102d98 < 65361 : 'left', < 65362 : 'up', < 65363 : 'right', < 65364 : 'down', ~/src/matplotlib-0.80/lib/matplotlib/backends/backend_qt.py 74,77d73 < qt.Qt.Key_Left : 'left', < qt.Qt.Key_Up : 'up', < qt.Qt.Key_Right : 'right', < qt.Qt.Key_Down : 'down', As you can see, it's reasonably straightforward to add these extra keys, so if anyone feels creative and wants other keys added, this should give an idea of what needs changing. As for my problem with gtk and the down key, I've rebuilt pygtk (2.6.1), installed matplotlib 0.80, and the problem is still there. I whipped up a trivial pygtk program which was a window which connected to key press events and it worked just fine, so it seems that there's something that matplotlib is doing which triggers the bug (that's not to say the bug is in mpl of course). I'm guessing there is something in my system setup which is flakey and causing it to happen, but it's 3am and I'm tired so I'll just live with it for now :) Cheers, Tim Leslie On Thu, 14 Apr 2005, Tim Leslie <ti...@cs...> wrote... > Just to follow up on this, I made the required changes to the other > backends and they worked fine. GTK and GTKAgg had the same broken > behaviour while TkAgg, WX and WXAgg worked fine (don't have qt installed). > > I'll bring all my libraries up to date (thanks for 0.80 tonight) and dive > into the pygtk stuff a bit deeper to see if I can find out what's > breaking. > > Having looked through a bit more mpl code I'd just like to say that I'm > very impressed with how simple it is to read. After working out what to > change in GTK, it followed an identical pattern in the other backends > which was very nice to see. > > Cheers, > > Tim Leslie > > On Thu, 14 Apr 2005, Tim Leslie <ti...@cs...> wrote... > > > On Wed, 13 Apr 2005, John Hunter <jdh...@ac...> wrote... > > > > > >>>>> "Tim" == Tim Leslie <ti...@cs...> writes: > > > > > > Tim> This all works fine except that the down key doesn't register > > > Tim> as released. After registering the down key press, no other > > > Tim> key events register until you hit the up key, at which point > > > Tim> the key release triggers for the up. > > > > > > It works fine for me -- what is your pygtk version and OS? > > > I'm using pygtk 2.2.0 on linux. > > > > AFAICT pygtk 2.0, this is running on ubuntu unstable. > > > > > > > > You might put some debug print statements to print event.keyval in > > > _get_key to see if an event is being triggered at the gtk level. > > > > OK, I'll have a play with that. > > > > > > > > Could it be a bad keyboard??? > > > > Yep :) Well, maybe. The down key works in every other app I use, but I've > > had problems with this keyboard in strange ways before, so I wouldn't put > > it past it. I'll try it out on another machine when I get a chance and see > > how it goes. It's a laptop, so I can't really change the keyboard. (hmm, > > maybe a usb external one, if I had one) > > > > > > > > Tim> I really don't know a lot about Gtk or the matplotlib > > > Tim> internals so I couldn't trace this bug deeper into the > > > Tim> libraries. Can anyone shed some light on what's going on? If > > > Tim> we can get the arrow keys working is there a chance of > > > Tim> getting them into the standard distribution (assuming we had > > > Tim> all backends working)? > > > > > > Absolutely. It might be nice to enable some standard keyboard > > > navigation too. > > > > OK well I'll play around with this some more and I'll get back to you once > > I have what I think is a complete, working patch. > > > > Cheers, > > > > Tim Leslie > > > > > > > > JDH > > > > > `- > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Matplotlib-users mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > `- > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > `- |
From: Tim L. <ti...@cs...> - 2005-04-13 15:02:48
|
Just to follow up on this, I made the required changes to the other backends and they worked fine. GTK and GTKAgg had the same broken behaviour while TkAgg, WX and WXAgg worked fine (don't have qt installed). I'll bring all my libraries up to date (thanks for 0.80 tonight) and dive into the pygtk stuff a bit deeper to see if I can find out what's breaking. Having looked through a bit more mpl code I'd just like to say that I'm very impressed with how simple it is to read. After working out what to change in GTK, it followed an identical pattern in the other backends which was very nice to see. Cheers, Tim Leslie On Thu, 14 Apr 2005, Tim Leslie <ti...@cs...> wrote... > On Wed, 13 Apr 2005, John Hunter <jdh...@ac...> wrote... > > > >>>>> "Tim" == Tim Leslie <ti...@cs...> writes: > > > > Tim> This all works fine except that the down key doesn't register > > Tim> as released. After registering the down key press, no other > > Tim> key events register until you hit the up key, at which point > > Tim> the key release triggers for the up. > > > > It works fine for me -- what is your pygtk version and OS? > > I'm using pygtk 2.2.0 on linux. > > AFAICT pygtk 2.0, this is running on ubuntu unstable. > > > > > You might put some debug print statements to print event.keyval in > > _get_key to see if an event is being triggered at the gtk level. > > OK, I'll have a play with that. > > > > > Could it be a bad keyboard??? > > Yep :) Well, maybe. The down key works in every other app I use, but I've > had problems with this keyboard in strange ways before, so I wouldn't put > it past it. I'll try it out on another machine when I get a chance and see > how it goes. It's a laptop, so I can't really change the keyboard. (hmm, > maybe a usb external one, if I had one) > > > > > Tim> I really don't know a lot about Gtk or the matplotlib > > Tim> internals so I couldn't trace this bug deeper into the > > Tim> libraries. Can anyone shed some light on what's going on? If > > Tim> we can get the arrow keys working is there a chance of > > Tim> getting them into the standard distribution (assuming we had > > Tim> all backends working)? > > > > Absolutely. It might be nice to enable some standard keyboard > > navigation too. > > OK well I'll play around with this some more and I'll get back to you once > I have what I think is a complete, working patch. > > Cheers, > > Tim Leslie > > > > > JDH > > > `- > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > `- |
From: John H. <jdh...@ac...> - 2005-04-13 14:59:58
|
Aric Hagberg at LANL just announced a graph package which uses matplotlib for drawing http://networkx.sourceforge.net/ Some cool screenshots at http://sourceforge.net/project/screenshots.php?group_id=122233 JDH |
From: Tim L. <ti...@cs...> - 2005-04-13 14:33:53
|
On Wed, 13 Apr 2005, John Hunter <jdh...@ac...> wrote... > >>>>> "Tim" == Tim Leslie <ti...@cs...> writes: > > Tim> This all works fine except that the down key doesn't register > Tim> as released. After registering the down key press, no other > Tim> key events register until you hit the up key, at which point > Tim> the key release triggers for the up. > > It works fine for me -- what is your pygtk version and OS? > I'm using pygtk 2.2.0 on linux. AFAICT pygtk 2.0, this is running on ubuntu unstable. > > You might put some debug print statements to print event.keyval in > _get_key to see if an event is being triggered at the gtk level. OK, I'll have a play with that. > > Could it be a bad keyboard??? Yep :) Well, maybe. The down key works in every other app I use, but I've had problems with this keyboard in strange ways before, so I wouldn't put it past it. I'll try it out on another machine when I get a chance and see how it goes. It's a laptop, so I can't really change the keyboard. (hmm, maybe a usb external one, if I had one) > > Tim> I really don't know a lot about Gtk or the matplotlib > Tim> internals so I couldn't trace this bug deeper into the > Tim> libraries. Can anyone shed some light on what's going on? If > Tim> we can get the arrow keys working is there a chance of > Tim> getting them into the standard distribution (assuming we had > Tim> all backends working)? > > Absolutely. It might be nice to enable some standard keyboard > navigation too. OK well I'll play around with this some more and I'll get back to you once I have what I think is a complete, working patch. Cheers, Tim Leslie > > JDH > `- |
From: John H. <jdh...@ac...> - 2005-04-13 14:23:44
|
>>>>> "Tim" == Tim Leslie <ti...@cs...> writes: Tim> This all works fine except that the down key doesn't register Tim> as released. After registering the down key press, no other Tim> key events register until you hit the up key, at which point Tim> the key release triggers for the up. It works fine for me -- what is your pygtk version and OS? I'm using pygtk 2.2.0 on linux. You might put some debug print statements to print event.keyval in _get_key to see if an event is being triggered at the gtk level. Could it be a bad keyboard??? Tim> I really don't know a lot about Gtk or the matplotlib Tim> internals so I couldn't trace this bug deeper into the Tim> libraries. Can anyone shed some light on what's going on? If Tim> we can get the arrow keys working is there a chance of Tim> getting them into the standard distribution (assuming we had Tim> all backends working)? Absolutely. It might be nice to enable some standard keyboard navigation too. JDH |
From: Philippe C. <kal...@ho...> - 2005-04-13 13:29:48
|
Hi everyone, I want to know if its possible to fix a value in the colorbar() which would change the level of transparency of every value under the limit value fixe in the colorbar. For exemple, if i want to show all values > 50, i can fix the limit value to 50 on the colorbar and plot is refresh to show only values upper than 50. Thanks for any answer. Philippe Collet |
From: Tim L. <ti...@cs...> - 2005-04-13 09:32:56
|
Hi all, I'm developing an app where i'd like the user to be able to navigate using the up/down/left/right keys. Currently the mpl event handlers just return None for these, but I figured it'd be easy enough to add the code myself. in lib/matplotlib/backends/backend_gtk.py I added the following diff, which adds in some new code -> string mappings and also notifies me when a key press or key release is made (for debugging). 109,112d108 < 65361 : 'left', < 65362 : 'up', < 65363 : 'right', < 65364 : 'down', 176c172 < --- > 184d179 < print "hit", key 189d183 < print "release", key This all works fine except that the down key doesn't register as released. After registering the down key press, no other key events register until you hit the up key, at which point the key release triggers for the up. If i hit the following sequence: [up, left, right, down, <any sequence not including up or down>, up, up] I get the following events registering. hit up release up hit left release left hit right release right hit down <== we never get the matching "release down" or anything else release up <== until we hit the up key and get this release event for it hit up release up I really don't know a lot about Gtk or the matplotlib internals so I couldn't trace this bug deeper into the libraries. Can anyone shed some light on what's going on? If we can get the arrow keys working is there a chance of getting them into the standard distribution (assuming we had all backends working)? Cheers, Tim Leslie |
From: Eric F. <ef...@ha...> - 2005-04-12 19:13:17
|
John, Attached are a slightly modified lines.py, based on CVS download this morning, and a demo of plotting masked arrays. The changes to lines.py are: 1) additional function imports from numerix 2) importing numerix.ma 3) a new function at the top of the file, unmasked_index_ranges. 4) changes to the draw and set_data methods 5) docstring indentation I think that with these fairly small changes, the plot command (or anything that uses Line2D to make lines or sets of markers) will work exactly the same as before with unmasked data, and will work correctly with masked data. That is, only the valid points will be plotted, and lines will be broken at gaps. I went for the simplest and least-intrusive changes I could find; maybe drawing the line segments could be improved by using the line collection renderer instead of a loop over ordinary line segments. It could also be optimized by not plotting line segments (as opposed to markers) when there is only one point. Let me know if you want me to look into any of these things; for now, I just wanted to get something working. The unmasked_index_ranges function, or some variation of it, might be useful outside lines.py. There are many ways it could be altered. I chose the 2-D array return, as opposed to a sequence of tuples, or a pair of 1-D arrays, in the hopes that it would be clear, efficient, and flexible; for example, it makes calculation of line segment lengths doable with a single "diff". In lines 263,264 of lines.py I put a question, not directly relevant to the changes I made, but pointing to what may be a minor oversight. I hope I haven't overlooked anything major! If all this is going in the right direction, I will add masked array support to contour.py later this week. It should be trivial. I would then be inclined to remove the "experimental" kwarg, badmask. Finding the bug in filled contours with masking remains to be done. Eric |
From: John H. <jdh...@ac...> - 2005-04-12 16:05:31
|
Every once in a while, when enough new features have been added and the nasty bugs ironed out, I tick the major version number and post a matplotlib release to the general python commuity. These releases are really just bug fix releases of the last release in disguise :-) I just uploaded matplotlib-0.80 to the web site. If you folks could be kind enough to give this a test drive and let me know if you hit any snags, I'd be much obliged. If all goes well, I'll do the general release tomorrow. What's new in 0.80 kwargs to xlim, ylim, axis Applied a variant of Rick Muller's xlim/ylim/axis patch. These functions now take kwargs to let you selectively alter only the min or max if desired. Eg xlim(xmin=2) or axis(ymax=3). They always return the new lim. See, eg help(xlim). The same functionality is available in the API with ax.set_xlim and ax.set_ylim . wx fixes Fixed a problem with wx app instantiation. Incorporated Werner's wx patch -- wx backend should be compatible with wxpython 2.4 and recent versions of 2.5. Some early versions of wxpython 2.5 will not work because there was a temporary change in the dc API that was rolled back to make it 2.4 compliant Polygon editors Added some proof of concept code to show how to use matplotlib to interact with plot elements in a GUI neutral way. The editable polygon allows you to insert, delete and move vertices. See examples/poly_editor.py. The idea it to add interactor classes to support editable lines, text, polygons, etc. This could support a cross GUI colormap editor, or spline editor, for example. http://matplotlib.sf.net Thanks! JDH |
From: Werner F. B. <wer...@fr...> - 2005-04-12 15:54:09
|
Hi John, Changing in pylab.py all the .__doc__ where either __doc__ + (only 1) or _shift_string (40 lines) is used to something along these lines: if not Axes.axhline.__doc__ == None: axhline.__doc__ = _shift_string(Axes.axhline.__doc__) + """ Addition kwargs: hold = [True|False] overrides default hold state""" This allows to use the py2exe/Python "Optimize: 2" option again and still have documentation available. Just tested it with the simple_plot_wxagg sample. See you Werner P.S. Attached the file for your perusal. |
From: Michael T. <mic...@gm...> - 2005-04-12 15:50:04
|
On Apr 12, 2005 3:13 PM, John Hunter <jdh...@ac...> wrote: > I saw the exact same thing but it appeared to come and go as I made > minor tweaks to the setup, and could never figure out why I sometimes > got this error and sometimes did not. I added nummaray to the > packages list. > I've googled on this but never found anything definitive. It'd be good if someone figured out what's happening as it's a fairly nasty error, but it's just easier to remember to stick that package in the packages list. > Yep, this is mentioned in the comment header of setup.py for the gtk > example (and in the FAQ). Still, it's easy to miss, as I spent about > 15 minutes trying to figure out what was going wrong (it had been many > months since I wrote the example) before I read my own comment. I > added a print reminder to setup.py. > (cough) Continuing my fine tradition of missing the helpful bits in documentation and comments. > Curious to know if this works for Andrea too. It appears to work for > me with py2exe 0.5.4 > I hope this works as it makes life a lot easier all round. If it doesn't I'd definitely suspect a bug in py2exe. > Michael> I've attached a diff showing the minor modifications I > Michael> made. > > Thanks, I've updated the examples on the site. > > I also saw your comment on the py2exe matplotlib wiki. I changed the > init method slightly -- could you test this on your setup to make sure > it works > Oh yeah, I'd forgotten about that wiki comment completely. I'll test the changed code this afternoon, thanks. cheers, Michael |
From: John H. <jdh...@ac...> - 2005-04-12 15:29:36
|
>>>>> "Sajec," == Sajec, Mike TQO <ms...@tq...> writes: Sajec,> Is there a simple way to grab x,y coordinates from active Sajec,> plot in a manner similar to using matlab's ginput() Sajec,> function? It depends on what you mean by simple :-) matplotlib provides a GUI independent way to capture basic events, eg to get the mouse coordinates in screen and data units and button clicks, key presses, etc. See http://matplotlib.sourceforge.net/tutorial.html#events Some people do not find callbacks intuitive. If you are one of these people, you might try something like the following from pylab import * class MouseMonitor: event = None def __call__(self, event): self.event = event mouse = MouseMonitor() connect('button_press_event', mouse) plot([1,2,3]) Now you can click on the plot, and get the coords like so print mouse.event.xdata, mouse.event.ydata See http://matplotlib.sourceforge.net/matplotlib.backend_bases.html#MouseEvent for more information on the mouse event attributes There are a couple of demos for event handling examples/keypress_demo.py examples/coords_demo.py JDH |
From: <na...@te...> - 2005-04-12 15:24:53
|
Greetings, Matplotlib has been helping me a lot, as always. I post so infrequently to this group because I usually don't have any problem getting what I want. However, I think I found a bug in stem. I've been stressing the stem function a lot, since I deal with signal processing. When plotting a demonstration of the overlap and save method (for performing long convolutions), I got something unexpected which the script below reproduces: --- from matplotlib.pylab import * n = arange(0, 2*pi, 2*pi/50, Float) x = sin(n) figure(1) stem(n, x, "k-", "ko", "k-") x[:26] = 0 savefig("test.eps") --- The sequence is plotted almost without any problems: the vertical lines are drawn with the correct amplitudes, but, because of the setting of some values of x to 0, the markers "fall down" to the axes. If I couldn't make myself clear, I can send an image of the result, but I think the script can reproduce the problem. I'm using the latest version of matplotlib, downloaded and installed yesterday. As it turns out, it actually *helped* me. Overlapp and save method consists in discarding some samples of the result. I couldn't think of a good way to actually show in a single figure how it would be done. I mention the bug, if it is really a bug, and not me doing something wrong, only to report it. I have no hurry to see it fixed - in fact, as it helped me, I don't plan to have it fixed soon. But I thought the developers would like to know it. Also, I would like to know if there is any way to customize the markers. There are some figures I need to make where the markers should be arrows pointing up. I modified "^" to look like what I wanted, but probably there is a better way to do that. Thanks in advance --- José Alexandre Nalon na...@te... |