On 09/18/2013 12:33 PM, Michael Droettboom wrote:
On 09/18/2013 12:28 PM, Matt Terry wrote:
On Wed, Sep 18, 2013 at 5:30 AM, Phil Elson <pelson....@gmail.com
<mailto:pelson....@gmail.com>> wrote:
Is it time to have the discussion about dropping the MacOS backend?
I know an incredible amount of top quality developer time has
gone into it, but in truth it is not up to the *Agg backends and
without another massive amount of work, never will be. Not to
mention the drag that having YAB (yet another backend) to
maintain and support adds.
Deleting the MacOS backend doesn't mean the end of its life - if
somebody cares enough they will probably set up a repo and
maintain it themselves, but I can think of a million and one
things I'd sooner have matplotlib developers working on than
getting the MacOS backend upto the *Agg standard.
Thoughts?
I'm not sure how much easier this will make our lives. The backend
options on mac are (in order of mpl's preference):
macosx (no deps)
qt4agg (needs qt)
gtk3agg (needs gtk)
tkagg (needs tk)
wxagg (needs wx)
Don't get me wrong, I am not thrilled with the macosx backend,
especially that can't-draw-outside-the-event-loop issue, but I doubt
that dropping it will make our lives easier. Its big advantage is
that it does not require a third-party windowing library.
If we drop macosx, we're going to have to deal with automated
installing of a windowing library. This is going to be hard because
mac doesn't have a package manager we can rely on (in fact it has 5
that sometimes coexist brew/macports/fink/manually installed dmg/pip).
The easiest target is probably tkagg. For that backend, there are
known (segfaulting) issues between different combinations of
macos/python.org-python/activetkl. So we will have to have an
assortment of binary installers to cover that problem. We will also
have to continue being wary of multiple versions of tkl installed on
the system.
This particular issue looks like a build problem. The change that
introduce the bug was in the 2to3->six transition, which shouldn't
have affect the internals, but obviously did.
I don't disagree with any of this, but we should add to consideration
the resurrection of the cocoaagg backend, based on pyobjc. It does
have the pyobjc dependency, but that is much smaller and less
problematic than the windowing toolkits mentioned.
Yet another option -- we reduce the MacOSX backend to just the minimum
required to display an Agg buffer on the screen and handle mouse and
keyboard events. Basically turn it into a GUI backend, not a GUI and
renderer backend. It would address Matt's dependency concern, while
also being a whole lot more maintainable.
Mike
------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
