matplotlib-devel Mailing List for matplotlib

On 22 March 2010 12:48, Jae-Joon Lee <lee...@gm...> wrote:
> I guess I misunderstood your original issue.
> I think I fixed this in r8210. So please give it a try.
Ah, thank you, that does appear to have solved it. (I'll double-check
when I don't have to run it through an ssh tunnel, but the display
looks good.)
Thanks,
Anne
> Regards,
>
> -JJ
>
>
> On Sun, Mar 21, 2010 at 6:42 PM, Anne Archibald
> <aar...@ph...> wrote:
>> On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>>>
>>>
>>> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
>>> wrote:
>>>>
>>>> Often when I want to
>>>> zoom in, I want to change only (say) the upper x and y limits.
>>>
>>> I pushed a change into the svn that enables this, but in a different way
>>> than you suggested.
>>> The behavior I implemented is similar to the current behavior of the "pan"
>>> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
>>> is updated. Same for "y" key.
>>> I hope this is good for your needs also.
>>
>> Well, it's an interesting feature, but it doesn't address the problem
>> I'm seeing.
>>
>> What I'd like to be able to do is, say, to change only the upper x and
>> y limits, simply click where I want those limits to be and drag right
>> off the corner of the plot. This actually works, but when I do this
>> the drag rectangle freezes the moment my pointer leaves the axes, so
>> that it does not represent the area being zoomed to.
>>
>> I've attached a screenshot illustrating the bug. Note where the
>> pointer is and where the "to be zoomed" rectangle is.
>>
>> I use Linux, with the default backend, whatever that is.
>>
>> Anne
>>
>>> Regards,
>>> -JJ
>>>
>>
>

On Mon, Mar 22, 2010 at 11:50 AM, Jörgen Stenarson
<jor...@bo...> wrote:
> Would it be possible to put the draw in the ipython_prompt hook. That
> way it is always called after you have done something.
I like this approach better, because one problem with doing it in the
mpl Artist layer is that one artist setter may call another, and
trigger a series of calls to draw for what is only a single draw at
the interactive prompt. ipython knows when an interactive call is
made, and can issue a draw. The trick will be to manage something
like a "needdraw" flag for all mpl figures, which is set when any
property contained in that fiugure changed and flushed when any call
to draw is made. If we maintain this flag on all mpl setters and
flush it after all mpl draws, the ipython prompt hook could check the
flag and draw if needed when interactive is True.
Not sure it is worth the effort, since like JJ I tend to mostly use
the pyplot functions when working from the interactive shell and don't
mind calling "draw" when using the API. I don't think API usage
should be encouraged for the interactive prompt -- but I don't think
it should be discouraged either -- it's just that in practice most
experienced users use the state machine in this case because it is
less typing and we needn't be pedantic, even when teaching <wink>.
JDH

Fernando Perez skrev 2010年03月22日 01:10:
> On Sat, Mar 20, 2010 at 4:00 PM, Jae-Joon Lee<lee...@gm...> wrote:
>> On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perez<fpe...@gm...> wrote:
>>> I wonder if it's possible to put things like a draw_if_interactive()
>>> call at the end of the OO methods... I realize that pyplot was the
>>> only one meant to do that, but if we are to encourage using the OO api
>>> more, then it's going to have to be as pleasant to use as pyplot... I
>>> don't know the codebase well enough to mess with this right now, so I
>>> hope someone who's more versed in that part of the code can make a fix
>>> for this whose impact isn't too severe on the runtime of OO code.
>>
>> I'm not very inclined to this but I'll wait to hear what others think.
>> I use oo api in the interactive mode but I still prefer to call draw()
>> explicitly.
>> Of course, we can make it optional.
>
> Mmh, back to this one: I do think it would be something useful to have
> somewhere, because typing draw() after *every* operation when working
> interactively does get tiresome, it seems to me... If we encourage
> calling subplots() for new teaching, then we do want it to be as
> pleasant as pyplot to use interactively, I think...
>
Would it be possible to put the draw in the ipython_prompt hook. That 
way it is always called after you have done something.
/Jörgen

I guess I misunderstood your original issue.
I think I fixed this in r8210. So please give it a try.
Regards,
-JJ
On Sun, Mar 21, 2010 at 6:42 PM, Anne Archibald
<aar...@ph...> wrote:
> On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>>
>>
>> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
>> wrote:
>>>
>>> Often when I want to
>>> zoom in, I want to change only (say) the upper x and y limits.
>>
>> I pushed a change into the svn that enables this, but in a different way
>> than you suggested.
>> The behavior I implemented is similar to the current behavior of the "pan"
>> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
>> is updated. Same for "y" key.
>> I hope this is good for your needs also.
>
> Well, it's an interesting feature, but it doesn't address the problem
> I'm seeing.
>
> What I'd like to be able to do is, say, to change only the upper x and
> y limits, simply click where I want those limits to be and drag right
> off the corner of the plot. This actually works, but when I do this
> the drag rectangle freezes the moment my pointer leaves the axes, so
> that it does not represent the area being zoomed to.
>
> I've attached a screenshot illustrating the bug. Note where the
> pointer is and where the "to be zoomed" rectangle is.
>
> I use Linux, with the default backend, whatever that is.
>
> Anne
>
>> Regards,
>> -JJ
>>
>

Rectangle selection also kind of bugs out when you reach the edge of the axes. I looked into fixing this a while ago and had a partial solution. The rectangle selector does some inaxes checking and relies on the xdata and ydata values. These are invalid outside the axes, but you can fake it by using the pixel values and a the axes transform. It might be worth adding a parameter to the rectangle selector to allow or disallow the rectangle to go outside of the axes.
-Ben
-----Original Message-----
From: Anne Archibald [mailto:per...@gm...] 
Sent: Monday, March 22, 2010 11:39 AM
To: Drain, Theodore R (343P)
Cc: mat...@li...
Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot
On 22 March 2010 11:32, Drain, Theodore R (343P)
<the...@jp...> wrote:
> I'd like to throw another vote in for this feature as well. We have a lot of cases like this and not being able to zoom to the limits of the window is a real head ache.
I'd just like to point out that it's the UI that's deceptive: you can
actually zoom to the edges by doing just what you'd expect, but the
box showing where you're zooming to is wrong.
Anne
> Back in the old days (when we were maintaining our own plot library), we solved this by allowing the bounding rectangle to be drawn outside the figure (assuming the mouse started inside the figure). When the mouse is released, the limits are reduced by the current axes values before applying the zoom. Something like:
>
> - mouse click outside the figure - handle like normal
> - mouse click inside the figure - start zooming
> - mouse drag - draw zoom box
> - mouse leaves figure - keep drawing zoom box (change from current havior)
> - mouse release - if mouse is outside figure zoom box started in, reduce zoom box to limits of axes (change from current behavior)
> - zoom
>
> Hope that helps...
>
> Ted
> ________________________________________
> From: Anne Archibald [aar...@ph...]
> Sent: Sunday, March 21, 2010 3:42 PM
> To: Jae-Joon Lee
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot
>
> On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>>
>>
>> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
>> wrote:
>>>
>>> Often when I want to
>>> zoom in, I want to change only (say) the upper x and y limits.
>>
>> I pushed a change into the svn that enables this, but in a different way
>> than you suggested.
>> The behavior I implemented is similar to the current behavior of the "pan"
>> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
>> is updated. Same for "y" key.
>> I hope this is good for your needs also.
>
> Well, it's an interesting feature, but it doesn't address the problem
> I'm seeing.
>
> What I'd like to be able to do is, say, to change only the upper x and
> y limits, simply click where I want those limits to be and drag right
> off the corner of the plot. This actually works, but when I do this
> the drag rectangle freezes the moment my pointer leaves the axes, so
> that it does not represent the area being zoomed to.
>
> I've attached a screenshot illustrating the bug. Note where the
> pointer is and where the "to be zoomed" rectangle is.
>
> I use Linux, with the default backend, whatever that is.
>
> Anne
>
>> Regards,
>> -JJ
>>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sun, Mar 21, 2010 at 8:10 PM, Fernando Perez <fpe...@gm...> wrote:
> Mmh, back to this one: I do think it would be something useful to have
> somewhere, because typing draw() after *every* operation when working
> interactively does get tiresome, it seems to me... If we encourage
> calling subplots() for new teaching, then we do want it to be as
> pleasant as pyplot to use interactively, I think...
>
I think the first issue that needs to be addressed is whether we want
to encourage OO api in the interactive mode (I mean, when a user
expect the figure gets updated as soon as a command is executed).
Using *subplots* does not necessarily mean that we need to use OO api,
since we now have *sca* in the pyplot namespace.
So. how other developers think?
Are we going to encourage OO api in the interactive mode?
Regards,
-JJ

You're correct - not sure what I was thinking of. 
I'm going to claim that it must have been this way in an older version and been fixed to make myself feel better...
________________________________________
From: Anne Archibald [per...@gm...]
Sent: Monday, March 22, 2010 8:39 AM
To: Drain, Theodore R (343P)
Cc: mat...@li...
Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot
On 22 March 2010 11:32, Drain, Theodore R (343P)
<the...@jp...> wrote:
> I'd like to throw another vote in for this feature as well. We have a lot of cases like this and not being able to zoom to the limits of the window is a real head ache.
I'd just like to point out that it's the UI that's deceptive: you can
actually zoom to the edges by doing just what you'd expect, but the
box showing where you're zooming to is wrong.
Anne
> Back in the old days (when we were maintaining our own plot library), we solved this by allowing the bounding rectangle to be drawn outside the figure (assuming the mouse started inside the figure). When the mouse is released, the limits are reduced by the current axes values before applying the zoom. Something like:
>
> - mouse click outside the figure - handle like normal
> - mouse click inside the figure - start zooming
> - mouse drag - draw zoom box
> - mouse leaves figure - keep drawing zoom box (change from current havior)
> - mouse release - if mouse is outside figure zoom box started in, reduce zoom box to limits of axes (change from current behavior)
> - zoom
>
> Hope that helps...
>
> Ted
> ________________________________________
> From: Anne Archibald [aar...@ph...]
> Sent: Sunday, March 21, 2010 3:42 PM
> To: Jae-Joon Lee
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot
>
> On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>>
>>
>> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
>> wrote:
>>>
>>> Often when I want to
>>> zoom in, I want to change only (say) the upper x and y limits.
>>
>> I pushed a change into the svn that enables this, but in a different way
>> than you suggested.
>> The behavior I implemented is similar to the current behavior of the "pan"
>> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
>> is updated. Same for "y" key.
>> I hope this is good for your needs also.
>
> Well, it's an interesting feature, but it doesn't address the problem
> I'm seeing.
>
> What I'd like to be able to do is, say, to change only the upper x and
> y limits, simply click where I want those limits to be and drag right
> off the corner of the plot. This actually works, but when I do this
> the drag rectangle freezes the moment my pointer leaves the axes, so
> that it does not represent the area being zoomed to.
>
> I've attached a screenshot illustrating the bug. Note where the
> pointer is and where the "to be zoomed" rectangle is.
>
> I use Linux, with the default backend, whatever that is.
>
> Anne
>
>> Regards,
>> -JJ
>>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 22 March 2010 11:32, Drain, Theodore R (343P)
<the...@jp...> wrote:
> I'd like to throw another vote in for this feature as well. We have a lot of cases like this and not being able to zoom to the limits of the window is a real head ache.
I'd just like to point out that it's the UI that's deceptive: you can
actually zoom to the edges by doing just what you'd expect, but the
box showing where you're zooming to is wrong.
Anne
> Back in the old days (when we were maintaining our own plot library), we solved this by allowing the bounding rectangle to be drawn outside the figure (assuming the mouse started inside the figure). When the mouse is released, the limits are reduced by the current axes values before applying the zoom. Something like:
>
> - mouse click outside the figure - handle like normal
> - mouse click inside the figure - start zooming
> - mouse drag - draw zoom box
> - mouse leaves figure - keep drawing zoom box (change from current havior)
> - mouse release - if mouse is outside figure zoom box started in, reduce zoom box to limits of axes (change from current behavior)
> - zoom
>
> Hope that helps...
>
> Ted
> ________________________________________
> From: Anne Archibald [aar...@ph...]
> Sent: Sunday, March 21, 2010 3:42 PM
> To: Jae-Joon Lee
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot
>
> On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>>
>>
>> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
>> wrote:
>>>
>>> Often when I want to
>>> zoom in, I want to change only (say) the upper x and y limits.
>>
>> I pushed a change into the svn that enables this, but in a different way
>> than you suggested.
>> The behavior I implemented is similar to the current behavior of the "pan"
>> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
>> is updated. Same for "y" key.
>> I hope this is good for your needs also.
>
> Well, it's an interesting feature, but it doesn't address the problem
> I'm seeing.
>
> What I'd like to be able to do is, say, to change only the upper x and
> y limits, simply click where I want those limits to be and drag right
> off the corner of the plot. This actually works, but when I do this
> the drag rectangle freezes the moment my pointer leaves the axes, so
> that it does not represent the area being zoomed to.
>
> I've attached a screenshot illustrating the bug. Note where the
> pointer is and where the "to be zoomed" rectangle is.
>
> I use Linux, with the default backend, whatever that is.
>
> Anne
>
>> Regards,
>> -JJ
>>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I'd like to throw another vote in for this feature as well. We have a lot of cases like this and not being able to zoom to the limits of the window is a real head ache.
Back in the old days (when we were maintaining our own plot library), we solved this by allowing the bounding rectangle to be drawn outside the figure (assuming the mouse started inside the figure). When the mouse is released, the limits are reduced by the current axes values before applying the zoom. Something like:
- mouse click outside the figure - handle like normal
- mouse click inside the figure - start zooming
- mouse drag - draw zoom box
- mouse leaves figure - keep drawing zoom box (change from current havior)
- mouse release - if mouse is outside figure zoom box started in, reduce zoom box to limits of axes (change from current behavior)
- zoom
Hope that helps...
Ted
________________________________________
From: Anne Archibald [aar...@ph...]
Sent: Sunday, March 21, 2010 3:42 PM
To: Jae-Joon Lee
Cc: mat...@li...
Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot
On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>
>
> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
> wrote:
>>
>> Often when I want to
>> zoom in, I want to change only (say) the upper x and y limits.
>
> I pushed a change into the svn that enables this, but in a different way
> than you suggested.
> The behavior I implemented is similar to the current behavior of the "pan"
> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
> is updated. Same for "y" key.
> I hope this is good for your needs also.
Well, it's an interesting feature, but it doesn't address the problem
I'm seeing.
What I'd like to be able to do is, say, to change only the upper x and
y limits, simply click where I want those limits to be and drag right
off the corner of the plot. This actually works, but when I do this
the drag rectangle freezes the moment my pointer leaves the axes, so
that it does not represent the area being zoomed to.
I've attached a screenshot illustrating the bug. Note where the
pointer is and where the "to be zoomed" rectangle is.
I use Linux, with the default backend, whatever that is.
Anne
> Regards,
> -JJ
>

I have two zorder-related complaints:
(1) The default zorder is not reasonable. If I plot a bar chart and then 
overlay a scatter diagram, the scatter diagram symbols are behind the 
bars. If I reverse the order, i.e., I generate the scatter diagram 
first, the scatter diagram symbols are still behind the bars. This 
doesn't make sense. Something that gets plotted later should be on top 
of whatever was plotted earlier.
(2) One really has to poke around to find the documentation for zorder. 
It would be great if the documentation for something as important as 
this were easier to find.
Thanks!
Phillip

On Sat, Mar 20, 2010 at 4:00 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perez <fpe...@gm...> wrote:
>> I wonder if it's possible to put things like a draw_if_interactive()
>> call at the end of the OO methods... I realize that pyplot was the
>> only one meant to do that, but if we are to encourage using the OO api
>> more, then it's going to have to be as pleasant to use as pyplot... I
>> don't know the codebase well enough to mess with this right now, so I
>> hope someone who's more versed in that part of the code can make a fix
>> for this whose impact isn't too severe on the runtime of OO code.
>
> I'm not very inclined to this but I'll wait to hear what others think.
> I use oo api in the interactive mode but I still prefer to call draw()
> explicitly.
> Of course, we can make it optional.
Mmh, back to this one: I do think it would be something useful to have
somewhere, because typing draw() after *every* operation when working
interactively does get tiresome, it seems to me... If we encourage
calling subplots() for new teaching, then we do want it to be as
pleasant as pyplot to use interactively, I think...
Is it technically expensive to put in?
Cheers,
f