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