matplotlib-devel Mailing List for matplotlib

On Wed, Nov 26, 2008 at 2:05 PM, John Hunter <jd...@gm...> wrote:
> I recently added support for a figure/axes enter/leave event. The
> figure enter and axes enter/leave are easy to do with nothing new in
> the backends, just using the native mpl events. The figure leave
> event is harder, because when a user leaves a figure and activates
> another window, mpl gets no events.
>
> To correct this, I added a leave_notify_event method to
> backend_bases.FigureCanvasBase (note this is not an mpl Event) but
> when called it will trigger a callback to those registered to the
> figure_leave_event with the last event that occurred in the window.
>
> I added support for this in gtk by connecting the the gtk signal
> 'leave_notify_event' to the mpl backend method leave_notify_event. If
> you know something about tk, wx or qt event handling, could you add a
> similar method to the appropriate backend? You can follow the example
> in backend_gtk.
>
>
> You can test with examples/event_handling/figure_axes_enter_leave.py
>
I implemented this in backend_qt4.
Darren

I used rsync to mirror the entire SVN repo locally and then using "git
svn clone" to import it (which took about 12 hours on a 2.5 GHz Core 2
machine, even with the local SVN mirror).
I haven't been able to clone the new git repo such that the 2nd git copy
would not need to do "git svn fetch" on the entire repository. Thus, it
seems that putting my git svn mirror in a publicly accessible location
isn't actually going to save anyone the pain of letting git call
subversion a bazillion times to import all history. (At least not
without me understanding things like
http://utsl.gen.nz/talks/git-svn/intro.html#howto-track-rebuildmeta )
I'll plan to use my local git repository to interact with the MPL svn
repo, but I don't plan to publish my git repo unless I figure out how to
set it up so it's actually useful. Until or unless that happens, here's
how I cloned the MPL repo:
# Directories
MPL_RSYNC_DIR="/mnt/workdisk/tmp/matplotlib-svn-rsync"
MPL_GIT_DIR="/mnt/workdisk/tmp/matplotlib"
# Copy the svn repo history locally
mkdir -p $MPL_RSYNC_DIR
cd $MPL_RSYNC_DIR
rsync -av matplotlib.svn.sourceforge.net::svn/matplotlib/* .
# Import into git
mkdir -p $MPL_GIT_DIR
cd $MPL_GIT_DIR
git svn clone --trunk=trunk/matplotlib --tags=tags \
 file://$MPL_RSYNC_DIR
At this point, you should have a shiny new git MPL repo in $MPL_GIT_DIR
suitable for use with git, including two of my favorites, git bisect and
gitk. However, to update from svn without going through the rsync
intermediate and to commit directly to the svn repo, you need to do the
equivalent of "svn switch --relocate" to point your git repo at the
SourceForge svn https URL rather than your local rsync copy. I'm at the
mercy of my google searching skills here because I don't understand how
git-svn works, but I followed the recipe at
http://www.ciaran-lee.com/articles/6 . Here it is modified to be
specific for this case:
* In the [svn-remote "svn"] section of $MPL_GIT_DIR/.git/config, change
the url to https://matplotlib.svn.sourceforge.net/svnroot/matplotlib
(but note the old file:/// URL -- you'll need that in a minute).
* (I think a commit has to have been made to the SourceForge SVN repo
for this next step to work. Somewhere in this recipe this has to happen,
and I forgot exactly where.)
* Run "git svn fetch" in $MPL_GIT_DIR
* Change the svn-remote url back to the original file:///
* Run "git svn rebase -l" to do a local rebase (with the changes that
came in with the last fetch operation)
* Change svn-remote url back to the new url.
* "git svn rebase" and "git svn dcommit" should now work.
Finally, a couple URLs that are useful for git-svn interaction:
* http://andy.delcambre.com/2008/3/4/git-svn-workflow
* http://git.or.cz/course/svn.html
And the man page:
* http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
Note that I'd actually suggest getting moderately comfortable with pure
git before attempting to do git/svn juggling. I suggest playing with the
sympy git repository: git clone git://git.sympy.org/sympy.git
Michael Droettboom wrote:
> I don't know of any, but if you create one let us know. I'd be 
> interested in playing with such a thing. I'm ready to see what all the 
> fuss is about... ;)
> 
> Mike
> 
> Andrew Straw wrote:
>> Since using git for some time on several projects (including projects
>> with a central svn repository), it's been hard to go back to the
>> universally slow web-based subversion history browsers and the absence
>> of 'git bisect'. Thus, I'm thinking about cloning the MPL SVN history
>> into a git repo, but I wonder if anyone has already done this? Are there
>> any git clones of the MPL svn repo out there?
>>
>> Thanks,
>> Andrew
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi Mike,
That does fix the issue. Another thing I noticed that is fixed with your
patch: the '.' marks appear like '+' when drawn at a smallish size.
Thanks,
Andrew
Michael Droettboom wrote:
> This might be related to a change I made in the Agg backend to make the
> markers look better by rounding their coordinates to the nearest pixel. 
> It certainly made the stock markers at a standard size look better, but
> I suspect as they get smaller, they are converging down to the same
> value, thus having a truly zero-sized marker.
> 
> I'm away from a machine with build tools at the moment, so can't
> confirm. Does the attached patch work for you?
> 
> Mike
> 
> Andrew Straw wrote:
>> John Hunter wrote:
>> 
>>> On Sat, Nov 29, 2008 at 3:55 PM, Andrew Straw <str...@as...>
>>> wrote:
>>> 
>>>> Hi All,
>>>>
>>>> I have been testing the latest svn matplotlib, which failed to produce
>>>> any visible data in some long-standing scripts of mine. :(
>>>>
>>>> Investigating further, my use of markersize=0.5 combined with the '.'
>>>> symbol and the Agg backend caused a complete disappearance of the
>>>> markers. I'm attaching example images from 0.93.3 and the most recent
>>>> SVN using the attached script.
>>>>
>>>> I'd be happy to track this down, but I think this might be a no-brainer
>>>> for someone on the list.
>>>> 
>>> Is this agg only?
>>> 
>>
>> It doesn't happen with PS or SVG, so I'll say yes.
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hello,
I have been working on reimplementation of the legend class, and I
guess it is mostly done. The biggest change is how each items are
placed. For this, I made a simple container class("offsetbox.py"),
which can pack the mpl artists in a similar way as widget packing in
gtk, tk, etc.
 * paddings are given as fraction of the font size.
 * baseline alignment (when supported by backend)
 * multicolumn
 * expand-mode (see the last panel in the attached figure)
 * fancybox for the frame
It should be backward compatible. The backend_driver.py runs fine and
all the examples I checked looks good.
So, here is the patch and example figure. It would be great if others
review and test this patch.
Regards,
-JJ

I don't know of any, but if you create one let us know. I'd be 
interested in playing with such a thing. I'm ready to see what all the 
fuss is about... ;)
Mike
Andrew Straw wrote:
> Since using git for some time on several projects (including projects
> with a central svn repository), it's been hard to go back to the
> universally slow web-based subversion history browsers and the absence
> of 'git bisect'. Thus, I'm thinking about cloning the MPL SVN history
> into a git repo, but I wonder if anyone has already done this? Are there
> any git clones of the MPL svn repo out there?
>
> Thanks,
> Andrew
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

This might be related to a change I made in the Agg backend to make the 
markers look better by rounding their coordinates to the nearest pixel. 
It certainly made the stock markers at a standard size look better, but 
I suspect as they get smaller, they are converging down to the same 
value, thus having a truly zero-sized marker.
I'm away from a machine with build tools at the moment, so can't 
confirm. Does the attached patch work for you?
Mike
Andrew Straw wrote:
> John Hunter wrote:
> 
>> On Sat, Nov 29, 2008 at 3:55 PM, Andrew Straw <str...@as...> wrote:
>> 
>>> Hi All,
>>>
>>> I have been testing the latest svn matplotlib, which failed to produce
>>> any visible data in some long-standing scripts of mine. :(
>>>
>>> Investigating further, my use of markersize=0.5 combined with the '.'
>>> symbol and the Agg backend caused a complete disappearance of the
>>> markers. I'm attaching example images from 0.93.3 and the most recent
>>> SVN using the attached script.
>>>
>>> I'd be happy to track this down, but I think this might be a no-brainer
>>> for someone on the list.
>>> 
>> Is this agg only?
>> 
>
> It doesn't happen with PS or SVG, so I'll say yes.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

John Hunter wrote:
> On Sat, Nov 29, 2008 at 3:55 PM, Andrew Straw <str...@as...> wrote:
>> Hi All,
>>
>> I have been testing the latest svn matplotlib, which failed to produce
>> any visible data in some long-standing scripts of mine. :(
>>
>> Investigating further, my use of markersize=0.5 combined with the '.'
>> symbol and the Agg backend caused a complete disappearance of the
>> markers. I'm attaching example images from 0.93.3 and the most recent
>> SVN using the attached script.
>>
>> I'd be happy to track this down, but I think this might be a no-brainer
>> for someone on the list.
> 
> Is this agg only?
It doesn't happen with PS or SVG, so I'll say yes.

On Sat, Nov 29, 2008 at 3:55 PM, Andrew Straw <str...@as...> wrote:
> Hi All,
>
> I have been testing the latest svn matplotlib, which failed to produce
> any visible data in some long-standing scripts of mine. :(
>
> Investigating further, my use of markersize=0.5 combined with the '.'
> symbol and the Agg backend caused a complete disappearance of the
> markers. I'm attaching example images from 0.93.3 and the most recent
> SVN using the attached script.
>
> I'd be happy to track this down, but I think this might be a no-brainer
> for someone on the list.
Is this agg only?
JDH

Since using git for some time on several projects (including projects
with a central svn repository), it's been hard to go back to the
universally slow web-based subversion history browsers and the absence
of 'git bisect'. Thus, I'm thinking about cloning the MPL SVN history
into a git repo, but I wonder if anyone has already done this? Are there
any git clones of the MPL svn repo out there?
Thanks,
Andrew

Hi All,
I have been testing the latest svn matplotlib, which failed to produce
any visible data in some long-standing scripts of mine. :(
Investigating further, my use of markersize=0.5 combined with the '.'
symbol and the Agg backend caused a complete disappearance of the
markers. I'm attaching example images from 0.93.3 and the most recent
SVN using the attached script.
I'd be happy to track this down, but I think this might be a no-brainer
for someone on the list.
-Andrew

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.
>
> http://wxpython.org/docs/api/wx.Cursor-class.html
> http://www.pygtk.org/docs/pygtk/class-gdkcursor.html
> http://doc.trolltech.com/4.4/qcursor.html
> http://www.tcl.tk/man/tcl8.4/TkCmd/cursors.htm
>
> 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

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....
Comments on the patch inline below.
On Fri, Nov 28, 2008 at 8:19 AM, Egor Zindy <ez...@gm...> wrote:
> A few things I added this time round:
> * showrange keyword (as per John's suggestion)
> * push keyword
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.
> 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.
> * 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.
> 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 :-)
> * more cursor types would be nice (could do with size_ver and size_hor in
> http://wiki.openusability.org/guidelines/index.php/Design_and_Layout:Visual_Design:Cursors).
> * took a long time to check out matplotlib from SVN, have yet to check the
> new events out.
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.
 http://wxpython.org/docs/api/wx.Cursor-class.html
 http://www.pygtk.org/docs/pygtk/class-gdkcursor.html
 http://doc.trolltech.com/4.4/qcursor.html
 http://www.tcl.tk/man/tcl8.4/TkCmd/cursors.htm
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.
> * 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...
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

A few things I added this time round:
* showrange keyword (as per John's suggestion)
* push keyword
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...
* 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).
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).
* more cursor types would be nice (could do with size_ver and size_hor 
in 
http://wiki.openusability.org/guidelines/index.php/Design_and_Layout:Visual_Design:Cursors). 
* took a long time to check out matplotlib from SVN, have yet to check 
the new events out.
* a nice name? (been struggling with that a lot lately!) Is "Bar" OK? or 
maybe "SelectionBar"?
As usual, comments welcome!
Regards,
Egor

Hi John,
John Hunter wrote:
> On Wed, Nov 26, 2008 at 11:57 AM, Egor Zindy <ez...@gm...> wrote:
>
> 
>> thank you, I'll have to check out the repository to see how I can use the
>> changes.
>>
>> Just a thought: a figure_leave / figure_enter event could be triggered by
>> comparing the currently held axis with event.inaxes (that's what Slider and
>> my bar widget do in _update() ).
>> 
>
> That's exactly how its done. The problem I referred to above (which
> will not affect your use case since you are leaving the axes) occurs
> when you want to connect to a figure leave event and move your mouse
> to a non-mpl window. Then we get no events to compare to the prior.
>
> JDH
> 
The new version attached that fixes a few of the things I was unhappy about:
* radius for clicking the bar now in pixels
* case when mouse pointer is outside the graph now handled correctly.
* commented the methods a bit more (still working on that)
Both these rely on the following two functions:
 #convert from x to xdata
 print self.ax.transData.inverted().transform_point((event.x, event.y))
 #convert from xdata to x
 print self.ax.transData.transform_point((event.xdata, event.ydata))
event.x always returns a value, so I used that to "fix" xdata when the 
cursor is outside the graph
Things I have struggled with (this time):
* 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).
* more cursor types would be nice (could do with size_ver and size_hor 
in 
http://wiki.openusability.org/guidelines/index.php/Design_and_Layout:Visual_Design:Cursors).
* took a long time to check out matplotlib from SVN, have yet to check 
the new events out.
* a nice name? (been struggling with that a lot lately!) Is "Bar" OK? or 
maybe "SelectionBar"?
Regards,
Egor

I can have a look at the qt backends, maybe this weekend.
On Wed, Nov 26, 2008 at 2:05 PM, John Hunter <jd...@gm...> wrote:
> I recently added support for a figure/axes enter/leave event. The
> figure enter and axes enter/leave are easy to do with nothing new in
> the backends, just using the native mpl events. The figure leave
> event is harder, because when a user leaves a figure and activates
> another window, mpl gets no events.
>
> To correct this, I added a leave_notify_event method to
> backend_bases.FigureCanvasBase (note this is not an mpl Event) but
> when called it will trigger a callback to those registered to the
> figure_leave_event with the last event that occurred in the window.
>
> I added support for this in gtk by connecting the the gtk signal
> 'leave_notify_event' to the mpl backend method leave_notify_event. If
> you know something about tk, wx or qt event handling, could you add a
> similar method to the appropriate backend? You can follow the example
> in backend_gtk.
>
>
> You can test with examples/event_handling/figure_axes_enter_leave.py
>
> Thanks,
> JDH
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I recently added support for a figure/axes enter/leave event. The
figure enter and axes enter/leave are easy to do with nothing new in
the backends, just using the native mpl events. The figure leave
event is harder, because when a user leaves a figure and activates
another window, mpl gets no events.
To correct this, I added a leave_notify_event method to
backend_bases.FigureCanvasBase (note this is not an mpl Event) but
when called it will trigger a callback to those registered to the
figure_leave_event with the last event that occurred in the window.
I added support for this in gtk by connecting the the gtk signal
'leave_notify_event' to the mpl backend method leave_notify_event. If
you know something about tk, wx or qt event handling, could you add a
similar method to the appropriate backend? You can follow the example
in backend_gtk.
You can test with examples/event_handling/figure_axes_enter_leave.py
Thanks,
JDH

On Wed, Nov 26, 2008 at 11:57 AM, Egor Zindy <ez...@gm...> wrote:
> thank you, I'll have to check out the repository to see how I can use the
> changes.
>
> Just a thought: a figure_leave / figure_enter event could be triggered by
> comparing the currently held axis with event.inaxes (that's what Slider and
> my bar widget do in _update() ).
That's exactly how its done. The problem I referred to above (which
will not affect your use case since you are leaving the axes) occurs
when you want to connect to a figure leave event and move your mouse
to a non-mpl window. Then we get no events to compare to the prior.
JDH

John Hunter wrote:
> On Wed, Nov 26, 2008 at 10:59 AM, John Hunter <jd...@gm...> wrote:
>
> 
>> probably fairly easy using a class level attr in the MouseEvent.
>> Another possibility would be to add support for figure_enter_event,
>> figure_leave_event, axes_enter_event, axes_leave_event. The user code
>> would have to separately process the axes_leave_event but this might
>> be the cleanest solution. I am happy to add support for these ...
>> 
>
> I just committed axes/figure enter/leave event notifications, with
> example in examples/event_handling/figure_axes_enter_leave.py. If you
> register for a leave event, you will get passed the last event that
> was in your axes/figure before it left
>
>
> Everything is working well with one caveat -- a figure leave event is
> only triggered when you enter a new figure, not simply when you leave
> the figure. This is because I just used the existing mpl
> LocationEvents to support the new events, and none of these are
> created when you are not over a canvas. To properly handle the figure
> leave events, we will need to tap into the underlying GUI leave
> events. The axes leave events work fine, with the one caveat that if
> the axes region is [0,0,1,1] you may not see the leave event for the
> same reason you do not see the figure leave event until you are over
> another canvas.
>
> JDH
> 
John,
thank you, I'll have to check out the repository to see how I can use 
the changes.
Just a thought: a figure_leave / figure_enter event could be triggered 
by comparing the currently held axis with event.inaxes (that's what 
Slider and my bar widget do in _update() ).
Cheers,
Egor

On Wed, Nov 26, 2008 at 10:59 AM, John Hunter <jd...@gm...> wrote:
> probably fairly easy using a class level attr in the MouseEvent.
> Another possibility would be to add support for figure_enter_event,
> figure_leave_event, axes_enter_event, axes_leave_event. The user code
> would have to separately process the axes_leave_event but this might
> be the cleanest solution. I am happy to add support for these ...
I just committed axes/figure enter/leave event notifications, with
example in examples/event_handling/figure_axes_enter_leave.py. If you
register for a leave event, you will get passed the last event that
was in your axes/figure before it left
Everything is working well with one caveat -- a figure leave event is
only triggered when you enter a new figure, not simply when you leave
the figure. This is because I just used the existing mpl
LocationEvents to support the new events, and none of these are
created when you are not over a canvas. To properly handle the figure
 leave events, we will need to tap into the underlying GUI leave
events. The axes leave events work fine, with the one caveat that if
the axes region is [0,0,1,1] you may not see the leave event for the
same reason you do not see the figure leave event until you are over
another canvas.
JDH

John Hunter wrote:
> On Wed, Nov 26, 2008 at 10:41 AM, Drain, Theodore R
> <the...@jp...> wrote:
>
> 
>> I'm pretty sure this is exactly what's happening. This is also 
>> annoying when you're trying to use a zoom rectangle and want to start 
>> at some point in the plot and drag it to the boundary. We've been 
>> planning on putting some time in to fix this this but just haven't 
>> been able to make the time yet.
>>
>> I think one possible solution is that anytime the mouse moves outside 
>> the axes, it should get one last event that is at the boundary which 
>> would require tracking which axes the last event was sent in. We 
>> haven't tried to see how hard that is to implement thought...
>> 
>
> probably fairly easy using a class level attr in the MouseEvent.
> Another possibility would be to add support for figure_enter_event,
> figure_leave_event, axes_enter_event, axes_leave_event. The user code
> would have to separately process the axes_leave_event but this might
> be the cleanest solution. I am happy to add support for these ...
> 
John,
in my code, I implemented tests like:
 if self.valmin is not None:
 if val < self.valmin:
 val = self.valmin
which makes limit handling better than that of the Slider class this was 
based on:
 if self.slidermin is not None:
 if val<=self.slidermin.val: return
Theodore nailed what is happening. At the moment, tests like the one I 
used cannot be implemented because event.xdata returns None when outside 
the boundaries. This cannot be compared with ax.get_xlim().
Maybe a value should be returned even when outside. the event.inaxes 
should be enough to know if the mouse pointer is inside or outside.
Although that would probably break a few things that at the moment 
depend on event.xdata being None when outside!

On Wed, Nov 26, 2008 at 10:41 AM, Drain, Theodore R
<the...@jp...> wrote:
> I'm pretty sure this is exactly what's happening. This is also annoying when you're trying to use a zoom rectangle and want to start at some point in the plot and drag it to the boundary. We've been planning on putting some time in to fix this this but just haven't been able to make the time yet.
>
> I think one possible solution is that anytime the mouse moves outside the axes, it should get one last event that is at the boundary which would require tracking which axes the last event was sent in. We haven't tried to see how hard that is to implement thought...
probably fairly easy using a class level attr in the MouseEvent.
Another possibility would be to add support for figure_enter_event,
figure_leave_event, axes_enter_event, axes_leave_event. The user code
would have to separately process the axes_leave_event but this might
be the cleanest solution. I am happy to add support for these ...
JDH

> > Things I struggled with:
> > * When a bar is dragged towards one of the figure edges too quickly,
> it gets
> > stuck in its last recorded position on the graph (that should be the
> figure
> > edge).
>
> I think the cause of this is when your mouse leaves the axes, the axes
> stops processing events, so it no longer gets updates to move the bar.
> I'm not sure what the right solution is though.
>
I'm pretty sure this is exactly what's happening. This is also annoying when you're trying to use a zoom rectangle and want to start at some point in the plot and drag it to the boundary. We've been planning on putting some time in to fix this this but just haven't been able to make the time yet.
I think one possible solution is that anytime the mouse moves outside the axes, it should get one last event that is at the boundary which would require tracking which axes the last event was sent in. We haven't tried to see how hard that is to implement thought...
Ted

On Wed, Nov 26, 2008 at 5:34 AM, Egor Zindy <ez...@gm...> wrote:
> Dear matplotlib devels,
>
> I wrote a selection widget someone else might find useful. The widget is
> based on the slider widget.>
> Things I implemented:
> * blitting (bar still flashes once when clicked on, sorry about that!)
> * Horizontal or vertical direction
> * Multiple selection bars on a figure
> * interaction between two bars to set a range
I think this is a useful tool, but I would like to see a few
enhancements, some of which you mention below.
> Things I struggled with:
> * When a bar is dragged towards one of the figure edges too quickly, it gets
> stuck in its last recorded position on the graph (that should be the figure
> edge).
I think the cause of this is when your mouse leaves the axes, the axes
stops processing events, so it no longer gets updates to move the bar.
 I'm not sure what the right solution is though.
> * Don't know how to change the mouse pointer when on top of the bar (the <->
> pointer for a vertical bar would be nice)
In backend bases there is a cursors enum:::
 In [5]: import matplotlib.backend_bases as bb
 In [7]: bb.cursors.HAND
 Out[7]: 0
 In [8]: bb.cursors.MOVE
 Out[8]: 3
and you can use the canvas toolbar to change the cursor
 In [11]: fig.canvas.toolbar.set_cursor(bb.cursors.MOVE)
> * Don't know how to define a range in pixels around the bar (for grabbing),
> so used 0.01 of the full range instead
Read the event handling and picking tutorial at
http://matplotlib.sourceforge.net/users/event_handling.html if you
haven't already. I suggest doing the hit testing in figure rather
than data coordinates. So instead of
 val = event.xdata
 if val < self.val + self.radius ...
do something like the following::
 def _update(self, event)
 # store the line location in pixel space
 self.linex = event.x
 def _press(event):
 if abs(event.x-self.linex)<=5: # 5 pixels
 # hit!
> * Haven't implemented dragging when a bar reaches the other bar (set with
> set_barmin or set_barmax) but hasn't reached the limit of its range.
>
> How to test:
> have mplbar.py and test_bar.py in the same directory, launch test_bar.py
>
>
> Hope this all makes sense (somehow I doubt it). And like I said, if you guys
> like it or want to adapt it further, please do, the code this is based on is
> yours after all!
With some additional cleanup along the lines of the above, I would be
happy to accept this. Please document every method (I realize some
exisint code does not meet this standard but we are trying to
improve). Also, please use the rest conventions when documenting new
code; the widgets code has not been ported over but a lot has -- see
http://matplotlib.sourceforge.net/devel/documenting_mpl.html
One feature you may want to consider. I think it would be nice to
have color coded ticks, or possibly a static hspan along the regions
where the bar can slide. Eg, see the following minor modification to
test_bar::
 bar1 = mplbar.Bar(ax1,valrange=[10,60],useblit=True, lw=2, color='g')
 ax1.axvspan(10, 60, ymin=0, ymax=0.05, facecolor='g', alpha=0.2)
 #range 10 to 60, init value set to 60, use blit, blue
 bar2 = mplbar.Bar(ax1,valrange=[10,60],valinit=60,useblit=True,
lw=2, color='b')
 ax1.axvspan(10, 60, ymin=0.95, ymax=1.0, facecolor='blue', alpha=0.2)
 #range 30 to +inf (None = no bound), default set to 30, use blit,
horizontal line, red
 bar3 = mplbar.Bar(ax1,valrange=[30,None],useblit=True,
direction='horizontal', lw=2, color='r')
 ax1.axhspan(30, 2*npts, xmin=0.95, xmax=1.0, facecolor='red', alpha=0.2)
Of course the use can always add this, so I am not sure if it is worth
building in... but support for something like this via a kwar might be
nice, eg
 Bar(blah, ..., showrange=True, rangespan=[0.95, 1.0])
JDH

Dear matplotlib devels,
I wrote a selection widget someone else might find useful. The widget is 
based on the slider widget.
Things I implemented:
* blitting (bar still flashes once when clicked on, sorry about that!)
* Horizontal or vertical direction
* Multiple selection bars on a figure
* interaction between two bars to set a range
Things I struggled with:
* When a bar is dragged towards one of the figure edges too quickly, it 
gets stuck in its last recorded position on the graph (that should be 
the figure edge).
* Don't know how to change the mouse pointer when on top of the bar (the 
<-> pointer for a vertical bar would be nice)
* Don't know how to define a range in pixels around the bar (for 
grabbing), so used 0.01 of the full range instead
* Haven't implemented dragging when a bar reaches the other bar (set 
with set_barmin or set_barmax) but hasn't reached the limit of its range.
How to test:
have mplbar.py and test_bar.py in the same directory, launch test_bar.py
Hope this all makes sense (somehow I doubt it). And like I said, if you 
guys like it or want to adapt it further, please do, the code this is 
based on is yours after all!
Regards,
Egor

Hi all,
thanks for the efforts put in this topic. A few hours after my initial 
post, I had a working quick&dirty cut&paste solution with minor source 
code changes without really knowing what I'm doing...
I'm glad that someone with a deeper understanding of the mpl internals 
is working on a mpl conform solution. I will subscribe to 
matplotlib-devel to keep track of the changes and help to test patches.
Regards
Simon
Paul Ivanov wrote:
> Hey John and the rest of the MPL gang:
> 
> I've made the changes you suggested, but the problem is looking to be
> deeper than it seemed. I'm also moving this conversation to
> matplotlib-devel, since that's probably the more appropriate place for
> it.
> 
> This updated patch allows for the creation of colormaps with various
> alphas, but there is likely more work to be done so that mpl can
> consistently make use of it (because it seems like all built-in cmaps
> are RGB, not RGBA).
> 
> In trying to come up with an example that exercises the new
> capabilities, I found out that methods like scatter and countourf modify
> the colormap you give them and reset all of the alpha values to 1.
> 
> I think this is because inside collections, we pass self._alpha, which
> is the Artist._alpha, and 1.0 by default, when making calls such
> as:
> _colors.colorConverter.to_rgba_array(c, self._alpha)
> 
> ...Thus resetting all of alpha values.
> 
> I was able to get around this by allowing collections to take on an
> alpha value of None, and then passing alpha=None to scatter and
> countourf, for example. There are probably other places where such a
> change should be done, unless someone has a better idea for how do do
> this. I updated examples/pylab/plot_scatter.py to show off the new
> capability.
> 
> Another thing that I was unable to get around is that if you now make a
> plot using the same colormap but omit the alpha=None parameter, or set
> it to something other than None, it will reset the alpha values on the
> previous plot:
> 
> figure(2)
> c = scatter(theta, r, c=colors, s=area,cmap=myColormap,alpha=None)
> 
> will do the right thing, but calling scatter without alpha=None
> 
> figure(3)
> d = scatter(theta, r, c=colors, s=area,cmap=myColormap)
> or
> d = scatter(theta, r, c=colors, s=area,cmap=myColormap, alpha=.5)
> 
> will reset all of the alpha values in myColormap to 1 or .5.
> You can do c.cmap._init() to reset its original alpha values, and if you
> force a redraw on figure(2) (by panning or zooming on it, for example),
> it will look right again. However, if you go and fiddle with figure(3)
> (pan/zoom), and come back to figure(2), panning or zooming will
> cause all of the alpha values will be reset again.
> 
> I'm not sure if it would be worth it to make a copy of the colormap to
> prevent this from happening. Anyone have thoughts on this?
> 
> (the full example of this is commented with FIXME: in polar_scatter.py)
> 
> best,
> Paul Ivanov
> 
> 
> John Hunter, on 2008年11月23日 07:36, wrote:
>> On Sun, Nov 23, 2008 at 2:01 AM, Paul Ivanov <piv...@gm...> wrote:
>>> I took a stab at it, how does this look?
>>>
>>> I also took the liberty of adding alpha to LinearSegmentedColormap and
>>> updated its docstring changing two somewhat ambiguous uses of the word
>>> 'entry' with 'key' and 'value'.
>> Hey Paul,
>>
>> Thanks for taking this on. I haven't tested this but I read the patch
>> and have some inline comments below. Some additional comments:
>>
>> * the patch should include a section in the CHANGELOG and
>> API_CHANGES letting people know what is different.
>>
>> * you should run examples/tests/backend_driver.py and make sure all
>> the examples still run, checking the output of some of the mappable
>> types (images, scaltter, pcolor...)
>>
>> * it would be nice to have an example in the examples dir which
>> exercises the new capabilities.
>>
>> See also, in case you haven't,
>> http://matplotlib.sourceforge.net/devel/coding_guide.html, which
>> covers some of this in more detail.
>>
>> Thanks again! Comments below:
>>
>> Index: lib/matplotlib/colors.py
>> ===================================================================
>> --- lib/matplotlib/colors.py	(revision 6431)
>> +++ lib/matplotlib/colors.py	(working copy)
>> @@ -452,7 +452,7 @@
>> self._isinit = False
>>
>>
>> - def __call__(self, X, alpha=1.0, bytes=False):
>> + def __call__(self, X, alpha=None, bytes=False):
>> """
>> *X* is either a scalar or an array (of any dimension).
>> If scalar, a tuple of rgba values is returned, otherwise
>> @@ -466,9 +466,10 @@
>> """
>> You need to document what alpha can be here: what does None mean, can
>> it be an array, scalar, etc...
>>
>> if not self._isinit: self._init()
>> - alpha = min(alpha, 1.0) # alpha must be between 0 and 1
>> - alpha = max(alpha, 0.0)
>> - self._lut[:-3, -1] = alpha
>> + if alpha:
>>
>> I prefer to explicitly use "if alpha is None", since there are other
>> things that would test False (0, [], '') that you probably don't mean.
>>
>> + alpha = min(alpha, 1.0) # alpha must be between 0 and 1
>> + alpha = max(alpha, 0.0)
>>
>> You should be able to use np.clip(alpha, 0, 1) here, but we should
>> consider instead raising for illegal alpha values since this will be
>> more helpful to the user. I realize some of this is inherited code
>> from before your changes, but we can improve it while making this
>> patch.
>>
>> + self._lut[:-3, -1] = alpha
>> mask_bad = None
>> if not cbook.iterable(X):
>> vtype = 'scalar'
>> @@ -558,9 +559,10 @@
>> def __init__(self, name, segmentdata, N=256):
>> """Create color map from linear mapping segments
>>
>> - segmentdata argument is a dictionary with a red, green and blue
>> - entries. Each entry should be a list of *x*, *y0*, *y1* tuples,
>> - forming rows in a table.
>> + segmentdata argument is a dictionary with red, green and blue
>> + keys. An optional alpha key is also supported. Each value
>> + should be a list of *x*, *y0*, *y1* tuples, forming rows in a
>> + table.
>>
>> Example: suppose you want red to increase from 0 to 1 over
>> the bottom half, green to do the same over the middle half,
>> @@ -606,6 +608,8 @@
>> self._lut[:-3, 0] = makeMappingArray(self.N,
>> self._segmentdata['red'])
>> self._lut[:-3, 1] = makeMappingArray(self.N,
>> self._segmentdata['green'])
>> self._lut[:-3, 2] = makeMappingArray(self.N,
>> self._segmentdata['blue'])
>> + if self._segmentdata.has_key('alpha'):
>> + self._lut[:-3, 3] = makeMappingArray(self.N,
>> self._segmentdata['blue'])
>>
>> Is this what you meant? I think you would use 'alpha' rather than
>> 'blue' here, no?
>>
>> self._isinit = True
>> self._set_extremes()
>>
>> @@ -664,11 +668,10 @@
>>
>>
>> def _init(self):
>> - rgb = np.array([colorConverter.to_rgb(c)
>> + rgba = np.array([colorConverter.to_rgba(c)
>> for c in self.colors], np.float)
>> self._lut = np.zeros((self.N + 3, 4), np.float)
>> - self._lut[:-3, :-1] = rgb
>> - self._lut[:-3, -1] = 1
>> + self._lut[:-3] = rgba
>> self._isinit = True
>> self._set_extremes()
>