[matplotlib-devel] Qt4 Backend
Hello, I have ported the existing Qt(3) backend to Qt4. Qt4 is a substantial change from Qt3; the Python bindings for Qt have also changed substantially. Since the two versions of Qt are likely to coexist for at least a while, I think it makes sense to have a separate Qt4 backend. How do I go about contributing my Qt4 backend? I have three files: backend_qt4.py, backend_qt4agg.py and embedding in qt4.py. Best, Jim Amundson --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building TkAgg backend without a running X server [revisited]
On Thu, 29 Nov 2007 18:13:39 +0200 Ludwig Schwardt <[EMAIL PROTECTED]> wrote: > I've reworked the Tcl/Tk checking code in setupext.py (see attached > patch). It is now possible to build matplotlib with Tk support without > requiring a running X server. This is useful for doing autobuilds > (e.g. as done by Debian) and for building a package on one machine to > be installed and used on another. > > This seems to be an old issue... (see matplotlib-devel, "building > matplotlib without X-server connection," 11 Nov 2004) I would like to register my strong support for this patch. The bug in question also prevents one from doing "python setup.py bdist_rpm" on rpm-based systems. I recently tried to debug this myself and got as far as identifying exactly the problem Ludwig describes, but ran out of time/energy before coming up with the fix. I am very grateful to Ludwig for having fixed the problem. I hope his patch will go in soon. --Jim Amundson - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] moving to the transforms branch
On Mon, 07 Jan 2008 19:54:38 -1000 Eric Firing <[EMAIL PROTECTED]> wrote: > Andrew Straw wrote: > > Something I haven't seen addressed on the numpy list (or here) is > > using hg or bzr to mirror an svn repository. What would be the > > added advantage to the project of using a DVCS if all the > > DVCS-ophiles would simply sync the svn tree? > > There has been numpy discussion of starting with a read-only mirror. > My sense is that doing two-way synchronization may be possible using > tailor, but it doesn't sound very practical. Without two-way > synchronization, getting changes from the user's DVCS committed back > to svn would be a clumsy process. I'm all for the DVCS concept. I have recently started using git for my own work, including reading the matplotlib repository. git includes built-in tools to talk to svn and cvs repositories. In fact, the reason I chose git over the alternatives (hg, bzr, etc.) is the way it allows me to use DVCS for my own work (and, occasionally, the work of my close collaborators) without requiring a change to an entire project's infrastructure. Using git in this way does not allow one to take advantage of all of the potential DVCS promises, but it goes a long way in the right direction. It's something to consider. Disclaimers: (a) I am not an active matplotlib developer. (b) I really don't want to start a git vs. hg vs. bzr discussion/flamewar. --Jim Amundson - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
