[matplotlib-devel] FltkAgg Patch
Hello All, I have attached a patch that updates backend_fltkagg.py to use the new Transform APIs for 0.98.0 ( http://matplotlib.sourceforge.net/api/api_changes.html#notes-about-the-transforms-refactoring). Without these changes, trying to use FLTKAgg causes a crash with a very cryptic error. Thanks for all your work on matplotlib! Daniel Index: lib/matplotlib/backends/backend_fltkagg.py === --- lib/matplotlib/backends/backend_fltkagg.py (revision 7174) +++ lib/matplotlib/backends/backend_fltkagg.py (working copy) @@ -115,6 +115,7 @@ window = Fltk.Fl_Double_Window(10,10,30,30) canvas = FigureCanvasFltkAgg(figure) window.end() +#Fltk.Fl.visual(Fltk.FL_DOUBLE) window.show() window.make_current() figManager = FigureManagerFltkAgg(canvas, num, window) @@ -157,7 +158,7 @@ def handle(self, event): x=Fltk.Fl.event_x() y=Fltk.Fl.event_y() -yf=self._source.figure.bbox.height() - y +yf=self._source.figure.bbox.height - y if event == Fltk.FL_FOCUS or event == Fltk.FL_UNFOCUS: return 1 elif event == Fltk.FL_KEYDOWN: @@ -230,7 +231,7 @@ def resize(self,size): w, h = size # compute desired figure size in inches -dpival = self.figure.dpi.get() +dpival = self.figure.dpi winch = w/dpival hinch = h/dpival self.figure.set_size_inches(winch,hinch) @@ -405,7 +406,7 @@ """ def __init__(self, canvas, figman): -#xmin, xmax = canvas.figure.bbox.intervalx().get_bounds() +#xmin, xmax = canvas.figure.bbox.intervalx #height, width = 50, xmax-xmin self.canvas = canvas self.figman = figman -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] building matplotlib-0.99.1.1.tar.gz on Mac OS X 10.6.1 (Snow Leopard)
Hello, With the caveat that I have not closely followed this mail list, I thought I would offer an alternate build method than what seems to be the preferred method for building matplotlib on Mac OS X. I tried to skim through recent mailing list posts to see if anything like this had been done, and did not immediately find anything. Forgive me if I'm repeating! As of Mac OS X 10.6.1, if you have X11 installed, you can build and use matplotlib without downloading anything else. (Unfortunately I have not yet had the opportunity to try this procedure out on a Leopard system.) First, I created a new setup.cfg on full auto: $ diff setup.cfg.template setup.cfg 25,26c25,26 < #pytz = False < #dateutil = False --- > pytz = auto > dateutil = auto 53,57c53,57 < #gtk = False < #gtkagg = False < #tkagg = False < #wxagg = False < #macosx = False --- > gtk = auto > gtkagg = auto > tkagg = auto > wxagg = auto > macosx = auto Then, I altered setupext.py so that the darwin config works like other operating systems. The difference is that I'm telling the script to look in /usr/X11, where freetype and libpng can be found on Mac OS X 10.6.1. $ diff setupext.py.orig setupext.py 53,54c53,54 < '_darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219', '/usr/ local', < '/usr', '/sw'], --- > # '_darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219', '/ usr/local', > # '/usr', '/sw'], 60c60 < 'darwin' : [], --- > 'darwin' : ['/usr', '/usr/X11',], Then, I run: $ sudo python setupegg.py install And matplotlib builds as a universal binary and installs an egg into / Library/Python/2.6/site-packages/ The setup process detects the included numpy 1.2.1 and freetype2 (unknown version*), and also detects libpng (unknown version*), Tkinter 67083, Tk 8.5, and Tcl 8.5. * freetype is 2.3.9; see /usr/X11/include/freetype2/freetype/freetype.h * libpng is 1.2.35; see /usr/X11/include/libpng12/png.h On a 64-bit system in the default configuration (like both of mine), there is no 64-bit version of the wxPython libraries to load, and so it is not detected. However, if I do: $ export VERSIONER_PYTHON_PREFER_32_BIT=yes ### see the python man page Then the setup process detects wxPython 2.8.8.1. I filed a bug with Apple about the lack of a 64-bit wxPython library, and it is Apple Problem ID # 7294359, in case anyone cares. The setup process does not detect Gtk+, Qt(4), or Cairo, because these are not included with Mac OS X (that I know of). Hope this is helpful! -Dan Huff ps -- As an aside, I create & edit ~/.pydistutils.cfg to allow an install for a per-user install as follows: $ cat ~/.pydistutils.cfg [install] install_lib = $HOME/Library/Python/$py_version_short/site-packages install_scripts = $HOME/usr/local/bin $ mkdir -p ~/Library/Python/2.6/site-packages $ python setupegg.py install This allows for more isolated testing in a sandbox user account. (end aside) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] repeated calls to show() are now OK?
Something that I have noticed:
When using TkAgg (python 2.5, OSX/ppc, mpl 99.0), isinteractive() switches
from False to True after the first call to show() (see below). When I
switch back ends, e.g. to Qt4, this change does not happen until I do it
myself through ion(). This was reproduceable on my intel mac, but since
updating to 99.1.1 (from source rather than Fink), I've broken the Tk
backend. Hope this helps; it may be a naive observation.
In [2]: import matplotlib as mpl
In [3]: mpl.use('TkAgg')
In [4]: import pylab as plt
In [5]: plt.isinteractive()
Out[5]: False
In [6]: plt.plot([0,1])
Out[6]: []
In [7]: plt.show()
In [8]: plt.isinteractive()
Out[8]: True
On Sun, Jun 13, 2010 at 9:36 AM, Michiel de Hoon wrote:
> --- On Fri, 6/11/10, Eric Firing wrote:
> > I agree that the difference in blocking behavior is still a
> > problem. I think that what we should do for now, *if* multiple
> > calls to show work on the Mac (which I can't easily test), is
> > change the documentation to correspond to the present situation,
> > highlighting the real problem of different blocking behavior.
>
> I now tried the remaining backends on Mac OS X. With the Qt4Agg and WxAgg
> backends, show() can be called repeatedly and blocks each time. The FltkAgg
> backend shows the same behavior as Tkagg. The implementation of show() in
> the FltkAgg backend uses the same _needmain as TkAgg. If I remove the
> _needmain stuff, then show() can be called multiple times with FltkAgg,
> blocking each time.
>
> --Michiel.
>
>
>
>
>
> --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] small patch for trunk/matplotlib/lib/matplotlib/axis.py
This is a small patch to enable get_gridlines to be able to get the grid lines for the minor ticks as well. 1052c1052 < def get_gridlines(self): --- > def get_gridlines(self,minor=False): 1054c1054,1055 < ticks = self.get_major_ticks() --- > if minor: ticks = self.get_minor_ticks() > else: ticks = self.get_major_ticks() -- Daniel Hyams dhy...@gmail.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] small patch for trunk/matplotlib/lib/matplotlib/axis.py
Sure:
--- axis.py 2010-08-18 09:59:25.0 -0400
+++ axis.py.orig2010-08-18 09:58:13.0 -0400
@@ -1049,12 +1049,9 @@
def _get_offset_text(self):
raise NotImplementedError('Derived must override')
-def get_gridlines(self,minor=False):
+def get_gridlines(self):
'Return the grid lines as a list of Line2D instance'
-if minor:
- ticks = self.get_minor_ticks()
-else:
- ticks = self.get_major_ticks()
+ticks = self.get_major_ticks()
return cbook.silent_list('Line2D gridline', [tick.gridline for tick
in ticks])
def get_label(self):
On Wed, Aug 18, 2010 at 1:05 PM, Ryan May wrote:
> On Wed, Aug 18, 2010 at 9:25 AM, Daniel Hyams wrote:
> > This is a small patch to enable get_gridlines to be able to get the grid
> > lines for the minor ticks as well.
> > 1052c1052
> > < def get_gridlines(self):
> > ---
> >> def get_gridlines(self,minor=False):
> > 1054c1054,1055
> > < ticks = self.get_major_ticks()
> > ---
> >> if minor: ticks = self.get_minor_ticks()
> >> else: ticks = self.get_major_ticks()
>
> Thanks for the contribution. Can you regenerate using: diff -u
> so we can easily apply to the tree?
>
> Thanks,
>
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>
--
Daniel Hyams
dhy...@gmail.com
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Release schedule for version 1.0.1?
On Mon, Oct 25, 2010 at 4:15 PM, Russell E. Owen wrote: > In article <4cc22964.1050...@stsci.edu>, > Michael Droettboom > wrote: > > > On 10/22/2010 05:45 PM, Russell E. Owen wrote: > > > I'm curious when the next release of matplotlib is due. > > > > > > My application is suffering badly from the issue that an incorrect font > > > cache will cause matplotlib to fail (the application mysteriously exits > > > partway through startup until the user deletes the font cache). > > > > > > That problem is allegedly fixed on the trunk and I'm trying to decide > > > how best to deal with it. Depending on the timing of 1.0.1 I can decide > > > whether it's worth putting in my own workaround, bundling a prerelease > > > version of matplotlib or just waiting for the official release. > > I'm not sure what the timeframe is on 1.0.1. > > > > What problem with the cache are you referring to? I'm aware of a > > problem where if some fonts are moved or removed after the cache is > > created matplotlib will crash (and this problem is fixed in the trunk), > > but is that really a problem in everyday practice? I'm just curious -- > > if there's another issue with the cache that I'm not aware of, I'd like > > to fix it. > > The known problem what I am referring to. Fortunately. > > It has proven to be a very serious problem in practice. I bundle > matplotlib into a Mac application and for a significant number of my > users it crashes at startup due to problems with the matplotlib cache > files. The fix is always the same: delete the cache. > > Some reasons this has happened > - The user first runs the application from the distribution dmg file > before copying to /Applications > - The user installs it and runs it, but then moves or renames it for > some reason...boom > - The user had an older version of matplotlib installed but then deleted > it for some reason. > > Fortunately the fix from the trunk will do the job. > > That said, it still seems risky to me that matplotlib insists on using a > shared directory for its cache and matplotlibrc file: that there's no > way to tell matplotlib to put that data somewhere else (e.g. inside the > application bundle). With bundled applications it is quite likely the > user may run multiple versions of matplotlib without even knowing it. If > any of that data is version-dependent then this is a recipe for > mysterious problems. > > It doesn't really insist on it right? There are MATPLOTLIBDIR and MPLCONFIGDIR environment variables. The former is for the location of mpl-data, and is not really documented well (that I could find, anyway, but I found it in the source code), and MPLCONFIGDIR specifies where your configuration files for matplotlib are. This is where your font cache will be, as well as your matplotlibrc. You can set these env variables within your code, before import of matplotlib via os.environment. -- Daniel Hyams dhy...@gmail.com -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Release schedule for version 1.0.1?
Right, I was referring specifically to MATPLOTLIBDIR ;) I was just pleased as punch to find it in the source code, documented or no :) On Mon, Oct 25, 2010 at 5:06 PM, John Hunter wrote: > On Mon, Oct 25, 2010 at 3:41 PM, Daniel Hyams wrote: > > > It doesn't really insist on it right? There are MATPLOTLIBDIR and > > MPLCONFIGDIR environment variables. The former is for the location of > > mpl-data, and is not really documented well (that I could find, anyway, > but > > I found it in the source code), and MPLCONFIGDIR specifies where your > > configuration files for matplotlib are. This is where your font cache > will > > be, as well as your matplotlibrc. > > > > You can set these env variables within your code, before import of > > matplotlib via os.environment. > > They should be better documented, but the MPLCONFIGDIR is in the FAQ > > > > http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#matplotlib-directory-location > -- Daniel Hyams dhy...@gmail.com -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] putting a legend in its place
I mailed this to the matplotlib-users list, but it never showed, so I'm trying this one. Apologies if it shows up in both places :( What I'm trying to do can be boiled down to the following: I'm trying to place a legend precisely, using the top left corner of legend as the "sticky" point. In other words, if I want to place the legend here: +-+---+ | | | | | legend | | | | | The plot... |---+ | | | | | | | | | | | | | | +-+ I would have thought that I would set bbox_to_anchor = (0,0,1,1), and loc = (1,1). I found out quickly, though, that this places the legend like this: +---+ | | | legend | | | +-+---+ | | | | | | | The plot... | | | | | | | | | | | | | | | +-+ Which makes perfect sense from matplotlib's perspective. So all I need to do is figure out how tall the legend is, and subtract that off the y coordinate before passing 'loc' off to matplotlib's legend. I just can't seem to figure out how to get that number. I tried self.ax.get_legend().get_frame().get_height(), but that just returns 1 all the time. I browsed all through the legend object (a live one) and just can't find any numbers at all that look like the legend width/height, in any coordinate system. I hope I'm missing something obvious! Ascii art is fun! :) -- Daniel Hyams dhy...@gmail.com -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] putting a legend in its place
I mailed this to the matplotlib-users list, but it never showed, so I'm trying this one. Apologies if it shows up in both places :( What I'm trying to do can be boiled down to the following: I'm trying to place a legend precisely, using the top left corner of legend as the "sticky" point. In other words, if I want to place the legend here: +-+---+ | | | | | legend | | | | | The plot... |---+ | | | | | | | | | | | | | | +-+ I would have thought that I would set bbox_to_anchor = (0,0,1,1), and loc = (1,1). I found out quickly, though, that this places the legend like this: +---+ | | | legend | | | +-+---+ | | | | | | | The plot... | | | | | | | | | | | | | | | +-+ Which makes perfect sense from matplotlib's perspective. So all I need to do is figure out how tall the legend is, and subtract that off the y coordinate before passing 'loc' off to matplotlib's legend. I just can't seem to figure out how to get that number. I tried self.ax.get_legend().get_frame().get_height(), but that just returns 1 all the time. I browsed all through the legend object (a live one) and just can't find any numbers at all that look like the legend width/height, in any coordinate system. I hope I'm missing something obvious! Ascii art is fun! :) -- Daniel Hyams dhy...@gmail.com -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] small bug report
In backend_wx.py, function Copy_To_Clipboard. A call to wx.TheClipboard.Flush() should follow wx.TheClipboard.Close(). If not, the data put on the clipboard does not persist after the wx application is closed. -- Daniel Hyams dhy...@gmail.com -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] improved source code for radar chart example in matplotlib docs
Hello dev people, I had an app where I needed the radar chart (aka Kiviat diagrams) source code out of matplotlib. Turns out the example source code is very limited the way it is currently written. Not good. I re-wrote parts of the source code to make it much more flexible and easier to include in an app. For example, if run in stand-alone mode, the user can specify upto 25 different radar charts in one window. Titles and labels are much more general as well. The legend can have multiple columns, etc. If anyone is interested, I will be happy to send you my source code, hoping you might consider replacing the current version in the docs with the one I'll send. Just reply and I'll send the code. You can decide from there whether to use it to replace current version. I did not want to attach the code if no one is interested. Daniel Barnette -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Calling all Mac OSX users!
On 22/08/2011, at 5:36, Benjamin Root wrote: > Ok, there has been a lot of useful discussion (for both MacOSX and Windows), > but in the end, I want to know this: Is it possible for matplotlib to provide > a single, recommended, fully-supported-by-us method for installing our > package (possibly for each platform?). Could it be pip? Or some other option? > > It is kinda sad that the linux install instructions are easier than the other > platform instructions, and I don't think we even provide a linux installer. It's pretty easy using MacPorts (thank you MacPorts maintainers :) sudo port install py27-matplotlib Obviously that doesn't help when building a dev version, although you can build out of tree ports. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] How to write a custom zoom behavior ?
* Short Story : I want to create my custom navigation bar with my custom zoom behavior: My first step is zooming by pressing +/- keys to zoom in and zoom out while pointing the mouse to the "zoom's center". I the long run I want a zooming and panning behavior interact smoothly with images (similar to photoshop's): - Zooming with the left button to zoom in the right button to zoom out. - Zooming with the mouse wheel. - Other interactions ... But I am stuck :-( * Question : My question is how do you "magnify" the image after change the axes ? (with self.axes.set_xlim((x1, x2)) self.axes.set_ylim((y1, y2)) ) * Long story: First, I wanted to understand how the zoom worked. So I traced the zoom functionality from the NavigationToolbar2Wx to the following method: - backend._bases.NavigationToolbar2.drag_pan From what I understand, this is where the magic bar happens? Now I wrote a dirty method ( see OnKeyPress below ) where I drive the zoom by changing the xmin,xmax,ymin,ymax when I press any key instead of the default mouse dragging behavior. When I zoom out: xmin,xmax = Xmin + 50, Xmax - 50 ymin,ymax = Ymin + 50, Ymax – 50 it works find. The image becomes smaller. But, when I zoom in as below xmin,xmax = Xmin - 50, Xmax + 50 ymin,ymax = Ymin - 50, Ymax + 50 the image just get cropped but not magnified. I other words self.axes.set_xlim and self.axes.set_ylim do not make the "data pixels bigger" (as happends in the correct zoom funcionality), they just stay the same size. The image becomes smaller and smaller instead of keeping the same size with les "data pixels into it"… def OnKeyPress(self, event): if not event.inaxes: return x, y = self.axes.transData.inverse_xy_tup( (event.x, event.y)) Xmin,Xmax=self.axes.get_xlim() Ymin,Ymax=self.axes.get_ylim() # Dirty hack to understand how zoom works xmin,xmax = Xmin - 50, Xmax + 50 ymin,ymax = Ymin - 50, Ymax + 50 if self.axes.get_xscale()=='log': alpha=log(Xmax/Xmin)/log(xmax/xmin) x1=pow(Xmin/xmin,alpha)*Xmin x2=pow(Xmax/xmin,alpha)*Xmin else: alpha=(Xmax-Xmin)/(xmax-xmin) x1=alpha*(Xmin-xmin)+Xmin x2=alpha*(Xmax-xmin)+Xmin if self.axes.get_yscale()=='log': alpha=log(Ymax/Ymin)/log(ymax/ymin) y1=pow(Ymin/ymin,alpha)*Ymin y2=pow(Ymax/ymin,alpha)*Ymin else: alpha=(Ymax-Ymin)/(ymax-ymin) y1=alpha*(Ymin-ymin)+Ymin y2=alpha*(Ymax-ymin)+Ymin self.axes.set_xlim((x1, x2)) self.axes.set_ylim((y1, y2)) self.canvas.draw() Any help would be welcomed! Daniel. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] blurry images at native resolution with images.BboxImage: patch to fix
I was playing around with images.BboxImage, and found that if I displayed,
say a 100x100 image at its native resolution (exactly 100x100 pixels on the
plotting window), it was blurred. This is because of the interpolation
jumping in and interpolating when it is not needed.
This might not be the best way to fix, but it does workin matplotlib
1.0.0, it is image.py around line 1102 (this is BboxImage.make_image). Just
after numrows and numcols is set in that routine, do
if (r-l) == numcols and (t-b) == numrows:
im.set_interpolation(0)
As you can see, all this does is just flip the interpolation off if the size
of the image is the same size that it is about to be rendered as...and the
regular interpolation is used otherwise.
I do apologize for the lack of a proper patch, but for little things like
this I think a word description works as well or better; I need to sit down
and both learn git and set of a development environment for matplotlib, but
after reading through the docs on the web site about it, decided that would
take me more time than I had at the moment.
In context:
def make_image(self, renderer, magnification=1.0):
if self._A is None:
raise RuntimeError('You must first set the image array or the
image attribute')
if self._imcache is None:
if self._A.dtype == np.uint8 and len(self._A.shape) == 3:
im = _image.frombyte(self._A, 0)
im.is_grayscale = False
else:
if self._rgbacache is None:
x = self.to_rgba(self._A, self._alpha)
self._rgbacache = x
else:
x = self._rgbacache
im = _image.fromarray(x, 0)
if len(self._A.shape) == 2:
im.is_grayscale = self.cmap.is_gray()
else:
im.is_grayscale = False
self._imcache = im
if self.origin=='upper':
im.flipud_in()
else:
im = self._imcache
# image input dimensions
im.reset_matrix()
im.set_interpolation(self._interpd[self._interpolation])
im.set_resample(self._resample)
l, b, r, t = self.get_window_extent(renderer).extents #bbox.extents
widthDisplay = (round(r) + 0.5) - (round(l) - 0.5)
heightDisplay = (round(t) + 0.5) - (round(b) - 0.5)
widthDisplay *= magnification
heightDisplay *= magnification
numrows, numcols = self._A.shape[:2]
if (r-l) == numcols and (t-b) == numrows:# <-
add this
im.set_interpolation(0)
#<-- and this
# resize viewport to display
rx = widthDisplay / numcols
ry = heightDisplay / numrows
#im.apply_scaling(rx*sx, ry*sy)
im.apply_scaling(rx, ry)
#im.resize(int(widthDisplay+0.5), int(heightDisplay+0.5),
# norm=self._filternorm, radius=self._filterrad)
im.resize(int(widthDisplay), int(heightDisplay),
norm=self._filternorm, radius=self._filterrad)
return im
--
Daniel Hyams
dhy...@gmail.com
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] blurry images at native resolution with images.BboxImage: patch to fix
> > > imshow() does take an "interpolation" kwarg, where you can specify > "nearest" for pre v1.1.0 versions and "none" (not None) in the recent > release. "nearest" would be close to what you want, while "none" is exactly > what you want. > > Personally, I don't think it would be a good idea to automatically turn > interpolation off on such a specific set of conditions, but I could be > wrong. I would rather have the user explicitly state their interpolation > intentions. > > Ben Root Hello Ben, Isn't the purpose of interpolation to handle situations where the image is being displayed at a different size than its native resolution? It seems appropriate to me to turn interpolation off in such a case. Just some context of what I was up to when I ran into this oneI'm trying to allow the user to paste images (either from file or clipboard) onto a matplotlib canvas and be able to drag and resize them, very similar to the way powerpoint works. So I wanted to work with the appropriate image object in matplotlib, and BboxImage was the best I found after digging in the code for a bit; imshow() is too tied to the axisthese are supposed to be just free floating images. What I ran into was that, on initial paste (where I am sizing the BboxImage the same width/height as the incoming picture), the image was very blurry (because of the interpolation). I still want the interpolation on so that the image looks nice when it is resized by the user with the grab handles, but in the specific case where no interpolation is needed, this patch turns it off. The pasting/dragging/resizing has actually turned out pretty well...once I get it cleaned up and working how I want it to, I'll submit it to you guys for inclusion into matplotlib if you want it. I was hoping to formulate it as a mixin that will work for any artist (not just BboxImage) within reasonable limits. -- Daniel Hyams dhy...@gmail.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] blurry images at native resolution with images.BboxImage: patch to fix
Ah yes, I forget :/ I was focused on images as being "pure" things that should be displayed, and forgot about the image processing angle. So would the solution be a keyword argument that tells imshow/BboxImage and friends not to interpolate when at native resolution, which is set to the current behavior as default? If that's not an acceptable solution, I can just leave the patch in my own personal code and not worry about any further...I thought that I was fixing a bug there :) I guess the main difference is whether the image is treated as sacred and should be displayed perfectly when possible, versus the ability to modify the picture on purpose via the interpolations, for whatever reason the user wants. Understandably, matplotlib has taken the latter approach, because the context has always been (as far as I can tell from the examples) displaying the pixels for a scientific purpose. However, when you want to display an image for a annotational type purpose, the former approach should be taken, in my opinion. On Thu, Oct 13, 2011 at 11:13 AM, John Hunter wrote: > On Thu, Oct 13, 2011 at 10:06 AM, Daniel Hyams wrote: > > > Isn't the purpose of interpolation to handle situations where the image > is > > being displayed at a different size than its native resolution? It seems > > Not solely, it can also be used to do local average of noisy images to > get a smoother view, eg bilinear or bicubic averaging of neighboring > pixels. > -- Daniel Hyams dhy...@gmail.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] draw() in Figure does not obey get_animated()
This could be intentional...I don't know much about the history of matplotlib, so it's hard to guess at these things. Anyway, the figure container does not care about the "animated" state of its artists when it does its drawing. To fix this, in the Figure.draw routine (in figure.py), add the following line just before dsu.sort(): dsu = [x for x in dsu if not x[1].im_self.get_animated()] -- Daniel Hyams dhy...@gmail.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] RFC: double click support in matplotlib
matplotlib doesn't support double clicks, and I was wondering if that was a design decision, or something that had been relegated to the "to do" box for someday. Hoping that it was still in the "todo" box, I think I can put most of it in without too much trouble, and supply you with a patch. The changes would be: 1) an extra flag MouseEvent, so that in a button_press_event handler, you can can tell if the press was a result of a double click or not, and 2) code in the backends to catch and set the double click flag properly I looked through the backends, and it was clear what to do in order to support double clicks for all but backend_macosx.py. I might be able to deduce what to do there, but will likely need some support from someone in order to get that one done. To support the double clicks, I would rather not create a new event like 'button_doubleclick_event', for backwards compatibility. I believe that if we just stick with 'button_press_event' and set an extra flag within the MouseEvent, any existing mpl code will still work properly, because the normal sequence of events on a double click are; DOWN, UP, DBLCLICK, UP. In current versions of matplotlib, the DBLCLICK event is treated as a DOWN, and the strategy of just adding a extra flag in MouseEvent would mean that existing mpl code would still see the double click event as a DOWN. Anyway, I want to "throw a feeler" out there, and ask if the patch would be accepted were I to go ahead and do it. I didn't want to spend the time working on it if a decision had already been made a while back to not ever support double clicks. -- Daniel Hyams dhy...@gmail.com -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC: double click support in matplotlib
I added double click support in, here in the following issue report: https://github.com/matplotlib/matplotlib/issues/550 I did use the extra flag in MouseEvent, but I can change this to a separate event if all think that it is appropriate; I still favor the flag for backwards compatibility. All backends are done except for cocoagg; see the issue report above for details. On Sat, Oct 22, 2011 at 10:57 PM, Benjamin Root wrote: > > > On Saturday, October 22, 2011, Daniel Hyams wrote: >> matplotlib doesn't support double clicks, and I was wondering if that >> was a design decision, or something that had been relegated to the "to >> do" box for someday. Hoping that it was still in the "todo" box, I >> think I can put most of it in without too much trouble, and supply you >> with a patch. >> >> The changes would be: >> 1) an extra flag MouseEvent, so that in a button_press_event >> handler, you can can tell if the press was a result of a double click >> or not, and >> 2) code in the backends to catch and set the double click flag properly >> >> I looked through the backends, and it was clear what to do in order to >> support double clicks for all but backend_macosx.py. I might be able >> to deduce what to do there, but will likely need some support from >> someone in order to get that one done. >> >> To support the double clicks, I would rather not create a new event >> like 'button_doubleclick_event', for backwards compatibility. I >> believe that if we just stick with 'button_press_event' and set an >> extra flag within the MouseEvent, any existing mpl code will still >> work properly, because the normal sequence of events on a double click >> are; DOWN, UP, DBLCLICK, UP. In current versions of matplotlib, the >> DBLCLICK event is treated as a DOWN, and the strategy of just adding a >> extra flag in MouseEvent would mean that existing mpl code would still >> see the double click event as a DOWN. >> >> Anyway, I want to "throw a feeler" out there, and ask if the patch >> would be accepted were I to go ahead and do it. I didn't want to spend >> the time working on it if a decision had already been made a while >> back to not ever support double clicks. >> > > My vote would be yes, but I think i would want it as a separate event. > Consider some of the widgets like lasso and the zoom bbox. If one were to > attach a button_press_event for the purpose of detecting double clicks, I > would imagine that there may exist conflicts (or those widget codes would > have to be adjusted to exclusively respond only to single clicks). Would > existing widgets also fire even if a double-click occured? > > My 2 cents, > Ben Rootl -- Daniel Hyams dhy...@gmail.com -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC: double click support in matplotlib
Ben: In current versions of matplotlib, the double click event is always just bound to the same handler as a single press. Such as the following code in backends/backend_wx.py: bind(self,wx.EVT_LEFT_DOWN,self._onLeftButtonDown) bind(self,wx.EVT_LEFT_DCLICK,self._onLeftButtonDown) bind(self,wx.EVT_LEFT_UP,self._onLeftButtonUp) so when someone double clicks on a canvas, the events sent would be (except in the case of gtk*) DOWN, UP, DOWN, UP. If a new event is created for the double click, the sequence of events generated would be DOWN,UP,DCLICK,UP. If you use a flag with in MouseEvent to signify the double click, the sequence of events would be DOWN,UP,DOWN.DCLICK,UP basically. This means that old code that relies on double clicks generating a DOWN event would still work, and newer code that wants to use double clicks need only query the MouseEvent.dblclick flag to see if a press was a double click or not. * for gtk, the event sequence for a double click is currently DOWN,UP,DOWN,DOWN,UP. That's the only backend that I've seen that does it this way. With the patch, the event sequence would be DOWN,UP,DOWN,DOWN.DCLICK,UP. On Sun, Oct 23, 2011 at 9:13 PM, Benjamin Root wrote: > > > On Sunday, October 23, 2011, Daniel Hyams wrote: >> I added double click support in, here in the following issue report: >> >> https://github.com/matplotlib/matplotlib/issues/550 >> >> I did use the extra flag in MouseEvent, but I can change this to a >> separate event if all think that it is appropriate; I still favor the >> flag for backwards compatibility. All backends are done except for >> cocoagg; see the issue report above for details. > > Thanks, I will look deeper into it tommorow. I am curious about what you > mean by backwards compatibility? How do you see having a new event type > cause issues? > > Ben Root > -- Daniel Hyams dhy...@gmail.com -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Possible bug in matplotlib.cbook.CallbackRegistry
lick on red sqaure again > > > > > > > > > > -- > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Daniel Hyams dhy...@gmail.com -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] which to fork from?
For small bugfixes, am I supposed to fork from v1.1.x, or master? -- Daniel Hyams dhy...@gmail.com -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] How to properly use git to implement a feature
I was wanting to add a feature to matplotlib...one that I would use in my application. I also want to contribute the feature back. I'm personally using version 1.1.1 of matplotlib. Disclaimer...I only know enough about git to be dangerous. So is it best to branch from v1.1.1, implement the feature, and then try to rebase to master? Or is it best to branch from master, implement the feature, and then (somehow) backport the patch to the v1.1.1 tagged version? Whatever the best choice is, what would the procedure look like to accomplish this? -- Daniel Hyams dhy...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to properly use git to implement a feature
Thanks Eric; this is what I was looking for, and it's a shame that there seems to be no way to accomplish this without cherrypicking a commit or range of commits. It seems that since v1.1.1 and master can be traced back to some common ancestry, that git should be able to rewind and replay the changes so that cherrypicking or reimplementing wouldn't be necessary. I've archived this email, though, so that I can use it at the appropriate time. For the immediate need, I was going to add the keyword 'bbox_size' to Annotations, so that the user can optionally specify the box size around an annotation...also was going to add additional boxstyles for Annotations, so that one could use a circle, ellipse, or any other type of patch to enclose the annotation. This would be useful for flowcharting and any other use where the user wants a "patch with text inside". As it stands, though I can only get 95% of this done...I can't seem to get the placement of the patch correct when the text is rotated, unless ha='center' and va='center', or if rotation_mode='anchor'. So since I would cause a regression here, I guess it's off the table. On Sun, Aug 12, 2012 at 11:23 PM, Eric Firing wrote: > On 2012/08/12 3:34 PM, Daniel Hyams wrote: > > > > I was wanting to add a feature to matplotlib...one that I would use in > > my application. I also want to contribute the feature back. I'm > > personally using version 1.1.1 of matplotlib. Disclaimer...I only know > > enough about git to be dangerous. > > > > So is it best to branch from v1.1.1, implement the feature, and then try > > to rebase to master? Or is it best to branch from master, implement the > > feature, and then (somehow) backport the patch to the v1.1.1 tagged > version? > > Mike answered for the case where you are making a bugfix that really > does go in v1.1.x. I think that even there, what he is recommending is > a bit different from what you have in mind: he is saying to branch from > an up-to-date v1.1.x, not from v1.1.1. Similarly, for the case you have > in mind, the pull request should be for a change relative to a recent > enough point on the master branch that it can be merged cleanly, and > with no unexpected side-effects. > > It sounds like what you are trying to do is maintain your own branch off > of the v1.1.1 tagged version, with only your own features added. > > I don't think there is any single best way to do this; it depends on how > you work, and on what sorts of changes you are making. > > Developing your change in your feature branch off of v1.1.1 is perfectly > reasonable, since that is where you are normally working, and that is > where you need it to work. To propagate it upstream, you do need to > either cherry-pick it, or reimplement it, relative to recent master. > Re-implementing it can be simpler in some cases--easier to see what is > going on! > > I had been thinking "rebase", but this is not correct; you don't want to > *remove* your commits from your branch off of v1.1.1, you want to > *reproduce* them, or their net effect, in a *new* topic branch off of > up-to-date master. > > It would go something like this. Assume "upstream" is the remote > pointing to the main mpl repo, and "origin" is your github repo. Assume > your changes are in a topic branch called "dh_topic_stable", off of > v1.1.1. Find the commit numbers in dh_topic_stable that you need to > propagate, say "a0b123fed" and "df237abc". > > git fetch upstream > git checkout -b dh_topic upstream/master > git cherry-pick a0b123fed df237abc > # build and test; maybe add documentation and test commits > git push origin dh_topic > > Then make your pull request against mpl master. > > For seeing what is in a repo, and what happens at each step of the way, > I find qgit helpful. Invoke as "qgit --all". You need to hit the > refresh button after each command-line git call. > > Eric > > > > > > Whatever the best choice is, what would the procedure look like to > > accomplish this? > > > > -- > > Daniel Hyams > > dhy...@gmail.com <mailto:dhy...@gmail.com> > > > > > > > -- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > > > &g
[matplotlib-devel] MEP9: interactivity
I'm not sure where to say that I just posted up a new MEP, but here it is: https://github.com/matplotlib/matplotlib/wiki/MEP9 and I suppose we discuss it here... -- Daniel Hyams dhy...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP9: interactivity
On Fri, Aug 17, 2012 at 10:52 AM, Drain, Theodore R (343P) < theodore.r.dr...@jpl.nasa.gov> wrote: > OK - I'll start the ball rolling... > > > > One feature that would be nice to have is positioning options that are not > pixel based. See the annotate function for some possibilities: > Note that the get_pixel_position_ll() and such functions (in the MEP9 proposal) are only for internal use by the interactive manager. Items can still be placed by the script wherever necessary, and if the position (in one or multiple transformations) is necessary, one can record that in the on_select_end callback for that artist. In fact, one of the things that must be done in the set_position_and_size() call (every artist will have to do this) is to set that artist's appropriate parameters for its position and size, based on its current transformation, that fits it within the bounding box that the user just finished moving and dragging around. Sorry, I know that's hard to see without some straw-man code that I intend to post soon...I was a little ashamed to post it in its current state ;) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP9: interactivity
On Fri, Aug 17, 2012 at 2:25 PM, Michael Droettboom wrote: > Here's my initial thoughts: > > There are a few examples in the event_handling that are going to be much > simplified by this new infrastructure. They should be updated to point > people in the direction of this new/better/easier way. > > How do the *select* methods relate to the existing pick functionality? > Does it replace or complement? Are there any inconsistencies in usage > between the two? > I think that in most use cases that I can think of, a user would want to either use the picking mechanism, which fires an event, or go "whole hog" and use the interactive manager. Not bothif I remember correctly, I do call set_picker() in the interactive manager, so that I can set a reasonable tolerance around the artist for containment purposes...otherwise it's too hard to point exactly at a line, for example. So there is some potential for interference there that would need to be looked after in the new code. As an aside, all of the on_* methods really encourage the user to use matplotlib in object oriented way, which I really like, but probably most people won't. As a bridge for the functional-style users of mpl, we could just implement all of the on_* methods in the artist.Artist class by default by having them fire an event. Then if someone overrides the method, fine, but if they don't, there is an event fired. > Other than that, I'm not seeing any obvious issues with the MEP. I'd love > to see the code when it's ready. > I'll probably have an example code, still in its mix-in form, in a branch for you to look at soon. This way, the discussion can turn more concrete. The example code will also be a runnable sample so that you can play with the interactivity. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP9: interactivity
I was planning to just create my own branch to start putting code in, but would it be better for an admin to create a branch off of master in the main matplotlib repo (say MEP9)? Then whoever wants to help out with MEP9 can branch from that and issue pull requests against it? On Fri, Aug 17, 2012 at 2:42 PM, Daniel Hyams wrote: > > > On Fri, Aug 17, 2012 at 2:25 PM, Michael Droettboom wrote: > >> Here's my initial thoughts: >> >> There are a few examples in the event_handling that are going to be much >> simplified by this new infrastructure. They should be updated to point >> people in the direction of this new/better/easier way. >> >> How do the *select* methods relate to the existing pick functionality? >> Does it replace or complement? Are there any inconsistencies in usage >> between the two? >> > > I think that in most use cases that I can think of, a user would want to > either use the picking mechanism, which fires an event, or go "whole hog" > and use the interactive manager. Not bothif I remember correctly, I do > call set_picker() in the interactive manager, so that I can set a > reasonable tolerance around the artist for containment purposes...otherwise > it's too hard to point exactly at a line, for example. So there is some > potential for interference there that would need to be looked after in the > new code. > > As an aside, all of the on_* methods really encourage the user to use > matplotlib in object oriented way, which I really like, but probably most > people won't. As a bridge for the functional-style users of mpl, we could > just implement all of the on_* methods in the artist.Artist class by > default by having them fire an event. Then if someone overrides the > method, fine, but if they don't, there is an event fired. > > >> Other than that, I'm not seeing any obvious issues with the MEP. I'd >> love to see the code when it's ready. >> > > I'll probably have an example code, still in its mix-in form, in a branch > for you to look at soon. This way, the discussion can turn more concrete. > The example code will also be a runnable sample so that you can play with > the interactivity. > > -- Daniel Hyams dhy...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP9: interactivity
On Fri, Aug 17, 2012 at 3:24 PM, Eric Firing wrote: > On 2012/08/17 8:45 AM, Daniel Hyams wrote: > > I was planning to just create my own branch to start putting code in, > > but would it be better for an admin to create a branch off of master in > > the main matplotlib repo (say MEP9)? Then whoever wants to help out > > with MEP9 can branch from that and issue pull requests against it? > > People can already do that by forking your repo (which you forked from > master), and issuing pull requests against your MEP9 branch within it. > The difference is that in the latter case, you are the only one who can > merge a pull request. I think this will have some advantages, including > giving you more freedom to do things like rebase and force-push, which > we would not want to do in the main repo. > > Eric OK, thanks Eric. I'll try my best not to let my git-ignorance "git" in the way too much ;) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP9: interactivity
OK, I have a sample code for people to run if they want to. I've dumped all of the interactive manager code and some sample usage (of the mix-in way of doing it) in the following branch: https://github.com/dhyams/matplotlib/tree/MEP9 in the directory examples/user_interfaces/imanager.py Just run that script, and it should give a little demo plot. I do apologize and disclaim all messiness in the code...it's not the prettiest thing anyway, and I cobbled it together very quickly so that you could see what it does. Sort of a straw man to beat on, I guess. On Fri, Aug 17, 2012 at 3:38 PM, Daniel Hyams wrote: > > > On Fri, Aug 17, 2012 at 3:24 PM, Eric Firing wrote: > >> On 2012/08/17 8:45 AM, Daniel Hyams wrote: >> > I was planning to just create my own branch to start putting code in, >> > but would it be better for an admin to create a branch off of master in >> > the main matplotlib repo (say MEP9)? Then whoever wants to help out >> > with MEP9 can branch from that and issue pull requests against it? >> >> People can already do that by forking your repo (which you forked from >> master), and issuing pull requests against your MEP9 branch within it. >> The difference is that in the latter case, you are the only one who can >> merge a pull request. I think this will have some advantages, including >> giving you more freedom to do things like rebase and force-push, which >> we would not want to do in the main repo. >> >> Eric > > > > OK, thanks Eric. I'll try my best not to let my git-ignorance "git" in > the way too much ;) > > -- Daniel Hyams dhy...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Is anyone using make.osx?
I do, but I'm not wedded to it; I'll use whatever is there. The convenience of it is that it downloaded dependencies and built them for you. Will setup.py do the same? On Fri, Sep 7, 2012 at 12:32 PM, Michael Droettboom wrote: > There is a discussion in a pull request about whether it is still needed. > > https://github.com/matplotlib/matplotlib/issues/751 > > It would be nice to have one obvious way to build on OS-X, so it makes > sense to remove this file in that case. However, I thought it might be > worth casting this question out before doing so. > > Cheers, > Mike > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Daniel Hyams dhy...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
