Hello, first of all let me say: Matplotlib is really
> great. I'm used looking at xplt-graphics and MPL is just
> For my programs I needed the coordinates of mouseclick and
> -release point so I modified the
> HorizontalSpanSelector. With the class in the attached
> file it is possible to use functions needing those
A nice example. I've been meaning to add something like this to
widgets.py. Do you mind if I include this under the matplotlib
license. I would probably rename it to something like
"RubberbandWidget" or RectangleSelector. For some reason, rectangular
region selection is often called "rubberbanding". I also suggest
making the callback pass eventPress and eventRelease rather than the
positions, because this is more flexible. For example, it gives the
user access to the window coords and key presses in addition to the x
and y data coords.
> In the example a large number of pionts is added to the
> plot so that you can check out performance improvments
> when using blitting. This however is only possible when
> calling python LinseSelector.py -dGTKAgg If using another
> backend blitting will not be possible right now (I don't
> know ehy,
The animation/blit API is new and requires some fairly low level
manipulation of pixel buffers and so on. To do this efficiently often
means writing extension code, so some of the other backends were a
little slower than others to implement it. Fortunately, thanks to the
hard work of Ken McIvor and Charles Moad, there is now also support
for WXAgg and TkAgg in CVS.
> I'm not very keen on this "manifold of backends"
I'm not sure exactly what this means, but I assume you think that
matplotlib is trying to support too many GUI toolkits. Perhaps. But
my philosophy is that the more developers you can get using
matplotlib, the more people will make useful contributions (like your
widget, hopefully). Since many groups are committed to a certain GUI
toolkit based on years of usage, they simply would not use matplotlib
if it didn't support their toolkit. Some of these people add support
if it is not there, and I am happy for it. It is a bit of a
maintenance hassle to support lots of toolkits across platforms, but
it mostly works.
> Although this works fine for my belongings I'm still
> unhappy with two things: - All this doesn't look like the
> normal connect('event',function)-style. It would be nicer
> if this LineSelector could also be handled in such a way.
One could define a drag_event in backend_bases. This would be
implemented in terms of the existing primitives (press, motion,
release) and so wouldn't require touching any backend code. Feel free
to take a crack at it if you are so inclined. As you note though, the
widget you've defined is perfectly functional.
> - If one uses this LineSelector the callback-function has
> to accept exactly two lenght-2 arays of floats (which
> means it is prescribed to the user). I'm not quite sure if
> this is very practical.
I'm not 100% sure what your problem with this is but as I said above,
passing events is more general.