Re: [matplotlib-devel] ginput: blocking call for mouse input
I'm not at all attached to any particular functionality. Feel free to
mangle it as you see fit!
On Feb 5, 2008 5:11 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Feb 5, 2008 3:58 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> > On Feb 2, 2008 8:48 AM, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> >
> > > Here is the new patch. I added visual feedback when accumulating points.
> > > I hope the docstrings are clear.
> >
> > Great -- thanks again. I applied this patch and created a new example
> > ginput_demo.py
>
> Jack replied to me offlist so I am going to paste in his post below.
> Perhaps you and Gael can consult on the ideal functionality of ginput
> vis-a-vis optional line segment drawing, etc...
>
>
>
> FromJack Sankey <[EMAIL PROTECTED]>
> to John Hunter <[EMAIL PROTECTED]>,
> dateFeb 5, 2008 4:02 PM
> subject Re: [matplotlib-devel] ginput: blocking call for mouse input
> mailed-by gmail.com
>
>
>
>
> Woa, it's working on GTKAgg using wx.Yield()? You must have added some voodoo
> :)
>
> Also, my version of GaelInput has seemed to stop evolving. This
> version has the option to draw lines between clicks, which I use a
> lot. Also, the default timeout is 0 now, since you can always
> right-click to abort.
>
> -Jack
>
>
>
> class GaelInput(object):
>"""
>Class that create a callable object to retrieve mouse click in a
>blocking way, a la MatLab. Based on Gael Varoquaux's almost-working
>object. Thanks Gael! I've wanted to get this working for years!
>
>-Jack
>"""
>
>debug = False
>cid= None # event connection object
>clicks = [] # list of click coordinates
>n = 1 # number of clicks we're waiting for
>lines = False # if we should draw the lines
>
>def on_click(self, event):
>"""
>Event handler that will be passed to the current figure to
>retrieve clicks.
>"""
>
># write the debug information if we're supposed to
>if self.debug: print "button "+str(event.button)+":
> "+str(event.xdata)+", "+str(event.ydata)
>
># if this event's a right click we're done
>if event.button == 3:
>self.done = True
>return
>
># if it's a valid click (and this isn't an extra event
># in the queue), append the coordinates to the list
>if event.inaxes and not self.done:
>self.clicks.append([event.xdata, event.ydata])
>
># now if we're supposed to draw lines, do so
>if self.lines and len(self.clicks) > 1:
>event.inaxes.plot([self.clicks[-1][0], self.clicks[-2][0]],
> [self.clicks[-1][1], self.clicks[-2][1]],
> color='w', linewidth=2.0,
> scalex=False, scaley=False)
>event.inaxes.plot([self.clicks[-1][0], self.clicks[-2][0]],
> [self.clicks[-1][1], self.clicks[-2][1]],
> color='k', linewidth=1.0,
> scalex=False, scaley=False)
>_pylab.draw()
>
># if we have n data points, we're done
>if len(self.clicks) >= self.n and self.n is not 0:
>self.done = True
>return
>
>
>def __call__(self, n=1, timeout=0, debug=False, lines=False):
>"""
>Blocking call to retrieve n coordinate pairs through mouse clicks.
>
>n=1 number of clicks to collect. Set n=0 to keep collecting
>points until you click with the right mouse button.
>
>timeout=30 maximum number of seconds to wait for clicks
> before giving up.
>timeout=0 to disable
>
>debug=False show each click event coordinates
>
>lines=False draw lines between clicks
>"""
>
># just for printing the coordinates
>self.debug = debug
>
># for drawing lines
>self.lines = lines
>
># connect the click events to the on_click function call
>self.cid = _pylab.connect('button_press_event', self.on_click)
>
># initialize the list of click coordinates
>self.clicks = []
>
># wait for n clicks
>self.n= n
>self.done = False
>t = 0.0
>while not self.done:
># key step: yield the processor to other threads
>_wx.Yield();
>_time.sleep(0.1)
>
># check for a timeout
>t += 0.1
>if timeout and t > timeout: print "ginput timeout"; break;
>
># All done! Disconnect the event and return what we have
>_pylab.disconnect(self.cid)
>self.cid = None
>return _numpy.array(self.clicks)
>
>
>
> def ginput(n=1, timeout=0, show=True, lines=False):
>"""
>Simple functional call for physicists. This will wait for n clicks
> from the user and
>return a list of the coordinates of each click.
>
>n=1 number of clicks to col
Re: [matplotlib-devel] A good, interactive plotting package
Gael Varoquaux wrote: > * pylab: I love the pylab API. I want (and I am not the only one) to > be able to construct a plot with a pylab script, or on the command > line. I would like to be able to modify it interactively > afterwards. Chaco's pylab equivalent is orders of magnitude below > the real pylab. I wonder why -- it sure looks doable. > * Output quality. Things like laTeX support, pdf and eps output, hmm -- I thought Kiva was designed around DisplayPDF, which you'd think would give you pdf support easily! > just an constant attention to small details like the tick size, > etc... give matplotlib an excellent output quality. Interesting, the examples I've seen of Chaco output sure look nice, but maybe it takes more tweaking to get there. > the two projects have different goals. The goals I see here seem to match pretty well: https://svn.enthought.com/enthought/wiki/ChacoProject Indeed, under PyCon2008 toDo, I see: "Fully verify PDF and SVG backends" also: "seemless install for chaco2 and chaco2demo packages for Win32, OS X, Ubuntu, Redhat" I did just find this (with some of your stuff, Gael), for a bit more info: http://code.enthought.com/chaco/docs/faq.shtml#comparison Some thoughts of mine: A few years back, before MPL, I was very excited about Chaco. however, at that time, Enthought ended up focusing on their needs, and things like non-Windows platforms, etc, were simple not supported. However, it looks like enthought is making a lot of effort to have their stuff play well with the open source community -- being able to use individual packages (traits, etc.), more support for other platforms, etc. So it comes a bit down to code base -- I think the goals of Chaco and MPL overlap a LOT -- I think different priorities have been put on them (more focus on GUI interactivity in Chaco, more focus on easy scripting in MPL), but both projects want to be able to do the same things in the long run. So it comes down to architecture, I guess -- which has the better architecture to build on in the future? I ahve no clue, I don't know either one well enough to comment. I guess it's time for me to dig into Chaco more. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] A good, interactive plotting package
On Mon, Feb 11, 2008 at 09:45:28AM -0800, Christopher Barker wrote: > Gael Varoquaux wrote: > > I am so happy to hear you say this. With Traits in MPL, it would be > > possible to build an interactive plotting application based around > > envisage, using other envisage plugins > I'm really not trying to be a troll, but tell me again what MPL has that > Chaco doesn't? It seems there is a bit of "we want MPL to be more like > Chaco", but Chaco is open source, and at least nominally back-end > independent, so why is there this duplicate effort? You are not at all a troll. I think this is a very important question to ask one self. I have thought about it a lot. Here is my answer: * pylab: I love the pylab API. I want (and I am not the only one) to be able to construct a plot with a pylab script, or on the command line. I would like to be able to modify it interactively afterwards. Chaco's pylab equivalent is orders of magnitude below the real pylab. * Output quality. Things like laTeX support, pdf and eps output, or just an constant attention to small details like the tick size, etc... give matplotlib an excellent output quality. I got used to it and I want to use it for all my publications, and actually I am quite happy having it for my day to day work to. I would love to see MPL and Chaco merge, to be able to get the best of both worlds, but I don't see it happening any soon, as the two projects have different goals. My 2 cents, Gaël - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] A good, interactive plotting package
Gael Varoquaux wrote: > I am so happy to hear you say this. With Traits in MPL, it would be > possible to build an interactive plotting application based around > envisage, using other envisage plugins I'm really not trying to be a troll, but tell me again what MPL has that Chaco doesn't? It seems there is a bit of "we want MPL to be more like Chaco", but Chaco is open source, and at least nominally back-end independent, so why is there this duplicate effort? From a glance, it sure looks like you could write a pylab work-alike around Chaco -- at least for wx -- other back-ends would be more work. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] set_xlim (and set_ylim) reset labels and tickers
When using unitized data any call to 'set_xlim' or 'set_ylim' will reset any user specified labels or tickers for a given axis and replace it with the values specified via the unitized data 'axisinfo' See the following for an example: ### from basic_units import cm, inch from pylab import figure, show import numpy cms = cm *numpy.arange(0, 10, 2) fig = figure() ax1 = fig.add_subplot(2,2,1) ax1.plot(cms, cms) ax2 = fig.add_subplot(2,2,2) ax2.plot(cms, cms, xunits=cm, yunits=inch) ax3 = fig.add_subplot(2,2,3) ax3.plot(cms, cms, xunits=inch, yunits=cm) ax3.set_xlabel( "My Label" ) ax3.set_xlim(3, 6) # scalars are interpreted in current units # Since we call set_xlim with unitized data, the label will be reset. ax4 = fig.add_subplot(2,2,4) ax4.plot(cms, cms, xunits=inch, yunits=inch) ax4.set_xlabel( "My Label" ) ax4.set_xlim(3*cm, 6*cm) # cm are converted to inches show() ### --James Evans - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
