matplotlib-users Mailing List for matplotlib (Page 7)

Olivier Bornet wrote:
> This is exactly what I'm searching for. But this is not really a Python
> syntax... The coma in the square brackets is not standard for lists.
> Maybe this come from the array type ?
Yes, it does. I you are doing anything MATLAB-y with Python, you really 
want to know about either numarray or Numeric. numarray is a little bot 
more like MATLAB (it allows array indexing), and Numeric has better 
performance with small arrays, but either will do for most uses. It 
looks like we're on the way to a grand unification of the two anyway.
Make sure you go find the docs f0or the package you choose, and read 
through them, I think you'll like them a lot!
By the way: aside from the looping, when you do:
x = A[i][j]
rather than:
x = A[i,j]
there is a performance hit because the first version is creating a new 
array out of A[i], then indexing into that, rather than just indexing 
directly into the 2-d (or more d) array. This is particularly pronounced 
with numarray, as the array creation overhead is larger than with Numeric.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

>>>>> "Olivier" == Olivier Bornet <Oli...@id...> writes:
 Olivier> Cool. :-D This is exactly what I'm searching for. But
 Olivier> this is not really a Python syntax... The coma in the
 Olivier> square brackets is not standard for lists. Maybe this
 Olivier> come from the array type ?
Yes, this is Numeric/numarray slicing, not list slicing. When you get
some time, you should read the pdf Numeric or numarray documentation.
It's comprehensive and very good.
Numarray also offers enhanced indexing ( Numeric does not yet) which
is a convenience you probably expect coming from matlab. Eg, you can
index an array with a sequence of integers (you must be careful that
the sequence is not a tuple however; lists or arrays of ints are ok)
 >>> import numarray as na
 >>> a = na.arange(0.0, 2.0, 0.1)
 >>> ind = [2,5,7]
 >>> a[ind]
 array([ 0.2, 0.5, 0.7])
JDH

>>>>> "Sascha" == Sascha Schnepp <sc...@te...> writes:
 Sascha> I often don't know which attributes can be used as
 Sascha> kwargs... 
Any Artist method that starts with 'set_' can be set with a kwarg.
Eg, if set_markeredgecolor is a method, you can do
markeredgecolor=something as a kwarg.
Read through the classdocs at
http://matplotlib.sourceforge.net/classdocs.html for the object of
interest, eg for lines (Line2D), see
http://matplotlib.sourceforge.net/matplotlib.lines.html
Also, you can call set(object) on any object and it will return the
current properties and their values (see also example/set_and_get.py)
BTW, the set and get introspection functionality was recently moved out of 
the pylab interface and now resides in matplotlib.artist so API
developers can use it as well
In [1]: lines = plot([1,2,3])
 
In [2]: set(lines)
 alpha: float
 antialiased or aa: [True | False]
 clip_box: a matplotlib.transform.Bbox instance
 clip_on: [True | False]
 color or c: any matplotlib color - see help(colors)
 dashes: sequence of on/off ink in points
 data: (array xdata, array ydata)
 data_clipping: [True | False]
 figure: a matplotlib.figure.Figure instance
 label: any string
 linestyle or ls: [ '-' | '--' | '-.' | ':' | 'steps' | 'None' ]
 linewidth or lw: float value in points
 lod: [True | False]
 marker: [ '+' | ',' | '.' | '1' | '2' | '3' | '4' | '<' | '>' | 'D' | 'H' | '^' | '_' | 'd' | 'h' | 'o' | 'p' | 's' | 'v' | 'x' | '|' ]
 markeredgecolor or mec: any matplotlib color - see help(colors)
 markeredgewidth or mew: float value in points
 markerfacecolor or mfc: any matplotlib color - see help(colors)
 markersize or ms: float
 transform: a matplotlib.transform transformation instance
 visible: [True | False]
 xclip: (xmin, xmax)
 xdata: array
 yclip: (ymin, ymax)
 ydata: array
 zorder: any number
 
In [3]:

Lists are 1-dimensional, so the comma doesn't really make sense.
You can, however, slice lists in python eg
 >>> x = range(100)
 >>> x[10:100:5]
[10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 90, 95]
You're right, that the commas come into play when you are dealing with 
the numarray (or numeric) arrays, where you may well have more than one 
dimension. It is a natural extension of the python slice syntax to 
multiple dimensions.
John
Olivier Bornet wrote:
>Hi,
>
>On Fri, Apr 15, 2005 at 12:32:45AM +1000, Tim Leslie wrote:
> 
>
>>You'll be pleased to know that the slicing works in almost exactly the
>>same in way python. Try:
>>
>>x2 = x[1:4,0:4]
>> 
>>
>
>Cool. :-D
>This is exactly what I'm searching for. But this is not really a Python
>syntax... The coma in the square brackets is not standard for lists.
>Maybe this come from the array type ?
>
> 
>
>>The indexing is slightly different, but I'm sure you can work it out.
>> 
>>
>
>Yes, no problem.
>
>Thanks for your help.
>
> Olivier
> 
>

Hi,
On Fri, Apr 15, 2005 at 12:32:45AM +1000, Tim Leslie wrote:
> You'll be pleased to know that the slicing works in almost exactly the
> same in way python. Try:
>=20
> x2 =3D x[1:4,0:4]
Cool. :-D
This is exactly what I'm searching for. But this is not really a Python
syntax... The coma in the square brackets is not standard for lists.
Maybe this come from the array type ?
> The indexing is slightly different, but I'm sure you can work it out.
Yes, no problem.
Thanks 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

On 2005年4月14日, Olivier Bornet <Oli...@id...> wrote...
> 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:
You'll be pleased to know that the slicing works in almost exactly the
same in way python. Try:
x2 = x[1:4,0:4]
The indexing is slightly different, but I'm sure you can work it out.
 
Tim
> 
> x = [[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)
> 
> ans =
> 
> 11 12 13 14
> 21 22 23 24
> 31 32 33 34
> 
> What I have done now in matplotlib is like:
> 
> x = 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] = 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
> -- 
> . __ . ___ __. | Olivier Bornet Oli...@id...
> / / ` / / / / / | IDIAP http://www.idiap.ch/~bornet/
> / / / / /--/ /--' | CP 592 http://www.idiap.ch/~bornet/pgp/
> / /__.' / / / / | CH-1920 Martigny PGP-key: 0xC53D9218
`-

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

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

Am 2005年4月14日 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
-------------------------------------------------------------------------=
--

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

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

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 2005年4月13日, 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 2005年4月14日, 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 2005年4月14日, Tim Leslie <ti...@cs...> wrote...
> > >>
> > >>
> > >>>On 2005年4月13日, 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
>

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

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

On 2005年4月13日, 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 2005年4月14日, 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 2005年4月14日, Tim Leslie <ti...@cs...> wrote...
> >>
> >>
> >>>On 2005年4月13日, 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
> 
`-

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

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 2005年4月14日, 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 2005年4月14日, Tim Leslie <ti...@cs...> wrote...
>>
>>
>>>On 2005年4月13日, 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

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

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 2005年4月14日, 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 2005年4月14日, Tim Leslie <ti...@cs...> wrote...
> 
> > On 2005年4月13日, 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
> 
`-

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 2005年4月14日, Tim Leslie <ti...@cs...> wrote...
> On 2005年4月13日, 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
> 
`-

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

On 2005年4月13日, 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
> 
`-

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

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

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