matplotlib-devel Mailing List for matplotlib

On Wed, Dec 3, 2008 at 6:43 AM, Gregor Thalhammer
<gre...@gm...> wrote:
>> Can you update, repatch wx to use it (and Darren qt)?
>
> I attached a patch that emits a enter_notify_event if the mouse enters the
> figure. Now the example behaves correctly.
Thanks Gregor -- just committed this. I don't have any other feedback
on the other points you and Darren are discussing yet....
JDH

On Wed, Dec 3, 2008 at 9:26 AM, Gregor Thalhammer <
gre...@gm...> wrote:
>
>
> 2008年12月2日 Darren Dale <dsd...@gm...>
>
>>
>>
>> On Tue, Dec 2, 2008 at 10:41 AM, John Hunter <jd...@gm...> wrote:
>>
>>> On Tue, Dec 2, 2008 at 8:34 AM, Gregor Thalhammer
>>> <gre...@gm...> wrote:
>>>
>>> > If a mouse button is pressed while leaving the figure the behaviour is
>>> > somewhat strange. First, a figure_leave_event is emitted. Then, further
>>> > moving the mouse outside the figure a new figure_enter_event is
>>> created.
>>> > This is the case since all mouse events, also movements outside the
>>> window,
>>> > are captured as long as a mouse button is pressed. This is a very
>>> convenient
>>> > behaviour for panning/zooming. However, when finally releasing the
>>> mouse
>>> > button no figure_leave_event is triggered. With the GTK backend such an
>>> > event is created.
>>> > So what should be the desired behaviour?
>>>
>>> Ahh, I hadn't considered this problem. It arises because I am using
>>> mpl location events to trigger the figure enter event. The solution
>>> is to use the gui event for the figure enter event too -- basically
>>> the gui needs to call the canvas.enter_notify_event. I added your
>>> patch and modified gtk to handle the enter_notify_event in svn r6468.
>>> Can you update, repatch wx to use it (and Darren qt)?
>>
>>
>> This is done for qt and qt4. In qt, if you hold the button, leave the
>> figure, enter the second figure, and release the button, the old figure
>> receives the leave event, but the new figure does not receive the enter
>> event. This seems like an issue with qt3, the new figure does receive the
>> enter event with qt4.
>>
>
> with the patched wx backend I observe the same behaviour. The second figure
> does not recieve an enter event. This might be because the wx backend
> captures the mouse if a button is pressed, i.e., all mouse events are
> redirected to the first figure.
>
> > I noticed that if one moves the cursor rapidly through the figure and
> axes, some events are not captured. For example, the cursor is in an axes
> but the last event the axes received was a leave event. I'm not sure how
> that could be improved, do you see it as well?
>
> Exactly this behaviour I can't see with the wx backend. Did I understood
> correctly: You manage to place the mouse within an axis, without having
> received a enter event?
>
Yes, this is the behavior I see.

2008年12月2日 Darren Dale <dsd...@gm...>
>
>
> On Tue, Dec 2, 2008 at 10:41 AM, John Hunter <jd...@gm...> wrote:
>
>> On Tue, Dec 2, 2008 at 8:34 AM, Gregor Thalhammer
>> <gre...@gm...> wrote:
>>
>> > If a mouse button is pressed while leaving the figure the behaviour is
>> > somewhat strange. First, a figure_leave_event is emitted. Then, further
>> > moving the mouse outside the figure a new figure_enter_event is created.
>> > This is the case since all mouse events, also movements outside the
>> window,
>> > are captured as long as a mouse button is pressed. This is a very
>> convenient
>> > behaviour for panning/zooming. However, when finally releasing the mouse
>> > button no figure_leave_event is triggered. With the GTK backend such an
>> > event is created.
>> > So what should be the desired behaviour?
>>
>> Ahh, I hadn't considered this problem. It arises because I am using
>> mpl location events to trigger the figure enter event. The solution
>> is to use the gui event for the figure enter event too -- basically
>> the gui needs to call the canvas.enter_notify_event. I added your
>> patch and modified gtk to handle the enter_notify_event in svn r6468.
>> Can you update, repatch wx to use it (and Darren qt)?
>
>
> This is done for qt and qt4. In qt, if you hold the button, leave the
> figure, enter the second figure, and release the button, the old figure
> receives the leave event, but the new figure does not receive the enter
> event. This seems like an issue with qt3, the new figure does receive the
> enter event with qt4.
>
with the patched wx backend I observe the same behaviour. The second figure
does not recieve an enter event. This might be because the wx backend
captures the mouse if a button is pressed, i.e., all mouse events are
redirected to the first figure.
> I noticed that if one moves the cursor rapidly through the figure and
axes, some events are not captured. For example, the cursor is in an axes
but the last event the axes received was a leave event. I'm not sure how
that could be improved, do you see it as well?
Exactly this behaviour I can't see with the wx backend. Did I understood
correctly: You manage to place the mouse within an axis, without having
received a enter event?
With all backends (Wx, GTK, Qt) I manage to leave the figure, without
leaving an axis. Either I move very fast, or I stack the figures on screen
so that I can leave an axis without touching the space around. We could emit
axes_leave_events (to all axes of the figure, or do we keep record which
axes has been entered recently?) before emitting a figure_leave_event, or
leave this to the users implementation of the figure_leave_event callback.
The first solution might lead to a lot of undesired redraws of the figure
when leaving the figure if several axes are contained in the figure and each
leave_axes callback issues a redraw, like in the example.
Gregor

>
> Can you update, repatch wx to use it (and Darren qt)?
>
I attached a patch that emits a enter_notify_event if the mouse enters the
figure. Now the example behaves correctly.
Gregor

Hi,
I just committed a patch (r6480) that reorganizes those transmuter
classes (used with fancybox & fancyarrows).
There are now three container classes (BoxStyle, ArrowStyle and
ConnectionStyle), and the trasnmuter classes are defined as subclasses
of these container classes.
With this change, the styles can be specified as any of the following
ways, although the last two may not be recommended.
 text(0, 0, "test", bbox=dict(boxstyle="round,pad=0.3"))
 text(0, 0, "test", bbox=dict(boxstyle=BoxStyle.Round(pad=0.3)))
 text(0, 0, "test", bbox=dict(boxstyle=BoxStyle("round,pad=0.3")))
 text(0, 0, "test", bbox=dict(boxstyle=BoxStyle("round", pad=0.3)))
Same for ArrowStyle and ConnectionStyle.
I also added two related examples.
 examples/pylab_examples/fancybox_demo2.py
 examples/pylab_examples/fancyarrow_demo.py
They show available boxstyles and arrowstyles, respectively.
I'm attaching the output figures.
Please let me know if the names I chose for the styles are funny or
don't make sense. Any suggestions will be appreciated.
Also, I tried to put some more documentation, although there should be
a lot of grammar and wording issues.
Regards,
-JJ

On Sun, Nov 30, 2008 at 9:42 PM, Andrew Straw <str...@as...> wrote:
> 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 always use this blog post to do exactly that:
http://subtlegradient.com/articles/2008/04/22/cloning-a-git-svn-clone
and it works very nicely. So please publish your repository somewhere,
so that others don't have to reclone the whole svn repo.
Thanks,
Ondrej
P.S. Michael, you should learn git. :)
P.P.S. Sorry I still didn't have time to port our 3D plotting from
sympy to matplotlib. Seems like a lot of people would welcome that,
but someone just needs to do it.