Hi John,
John Hunter wrote:
Hi Egor -- thanks for the update. For future posts on the same theme,
could you please respond to the existing thread rather than creating a
new one. This makes it easier for people who are following a thread
to keep following it, and those ignoring it to keep ignoring it.
Importantly, for future generations of googlers and nabblers, it makes
it easier to follow a single conversation. If you feel like you
earlier post fell on deaf ears because you got no response, its more
likely that we fell behind than that we didn't see it, because all of
us have threaded news readers. Just "bump" the thread with a polite
and gentle "did anyone have a chance to test this?" rather than
creating a new thread....
Sorry about the new thread. What you wrote makes a lot of sense, so thank you for taking the time to write the list rules down. Big thumbs up for following this up John, appreciated! There's no rush though and I hope I'm not pressurising any of the devs to answer my problems! Just kick me out if that's what you feel 
This is a nice enhancement -- could you also add a keyword arg so
users can customize the min/max of the span. You've hardcoded
[0.99...1], which may be a little tight for some users. Also, it
prevents being able to place one span on left, one on right, for
multiple bars, etc.. Something like rangelim=[0.99, 1.0] as a kwarg
should be fine.
Yes, overlapping ranges will be much easier to visualise with visual queues of different thickness. I thought that with an alpha of 0.2, the colours would blend, but they don't? anyway, new keyword coming!
New problems:
* Not sure how to make an axvspan / axhspan span from -inf to value or value
to +inf. I use None in my valrange keyword to indicate that but using None
as an argument in axvspan doesn't help much...
This is a bit tricky. Probably the best way to do it is to connect to
the xlim_changed and ylim_changed events of the Axes, and update the
bar line to encompass the current view limits.
This is good! I can also check how this is done with the hlines / vlines I'm using for the selector itself, maybe there's some code I can borrow in there.
* My push keyword kind of works now (see the example, green line can push
the blue line) but the implementation is a real mess. I might have to
rewrite the blitting (I need a background image with none of the bars so
that I can use that for blitting).
I am not seeing any effect of push when I push the green line over to
blue in your example; not exactly sure what is supposed to happen.
If you set the animated property on all the bar lines, none of them
will be rendered on a normal draw, which may help you control the
blitting.
OK, I'll try and explain that again using the my test example, the green selector (GS, left) and blue selector (BS, right). The two selectors are linked together with barmin and barmax, so that GS can move from 10 to BS and BS can move from GS to 60. with the push keyword enabled, a selector can push (nudge better?) its barmin/barmax to either the limit of its own range or to the limit of the barmin/barmax range, whichever is reached first.
To test this in test_bar.py, start with GS at 10, bring BS around 20, then move GS towards the upper limit of its range. GS nudges BS out of its current position and both selectors are moved towards the upper limit (60, same for both GS and BS in my test case).
I'm working on problems where I need to easily select time intervals. I feel that this nudging business provides a good "one click" selection to these kind of problems: Push the upper selector with the lower selector and when the new upper range is reached, pull back to the new lower position. This is possibly better than moving the lower selector first, then moving the upper selector.
Like I said, the implementation is very poor (far too much redrawing going on), but it works as a demonstration, and allowed me to fix the problem when a selector "becomes stuck".
The next stage would be to scroll the data when a selector reaches either side of the graph, but not its hard limits.
Other problems (in my previous posts) still stand:
* there is a toobar.set_cursor() but no toolbar.get_cursor() which would be
interesting to have to set the cursor back to what it should be (rather than
arbitrary POINTER type).
You can add a get_cursor method in your next patch -- see below
Thanks, I'll do that. I'll add a patch to the original slider too.
I would be happy to accept as many cursor types as you want to add.
The trick is that we need to support them across the 4 major user
interfaces (tk, wx, gtk, qt). So we shouldn't go crazy with lots of
cursor types that we can't support across backends. If you would like
to patch backed_bases and one or more of the other user interface
backends, we can extend the number of cursors we support.
wxPython API Documentation — wxPython Phoenix 4.2.1 documentation
Overview — PyGObject
http://doc.trolltech.com/4.4/qcursor.html
Tk Built-In Commands - cursors manual page
We don't have to support the least common denominator of all these,
but it would be nice to support all the cursors that all support, and
maybe a few more that one or more don't support but can use a
reasonable proxy for. If you are interested in adding support for
this in your next patch, that would be great.
Apart from QT, I think I can test all the others with a mix of ubuntu/xp.
* a nice name? (been struggling with that a lot lately!) Is "Bar" OK? or
maybe "SelectionBar"?
I am not wild about Bar either -- how about ScalarSelector, which is a
fits in fairly well with the existing SpanSelector...
Excellent! I really like it. ScalarSelector it is, then!
When you are ready to submit something for inclusion in mpl, please
get a fresh svn checkout (slow or not) and submit a svn diff -- see
http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto
JDH
No probs, I'll do that. Checking matplotlib out for the first time takes a long time though. I'll get there eventually, I guess!
Thanks again for your help and feedback.
Regards,
Egor