Re: [matplotlib-devel] master macosx backend broken?

[Michael D. <md...@st...>]

On 09/18/2013 12:28 PM, Matt Terry wrote:
> On Wed, Sep 18, 2013 at 5:30 AM, Phil Elson <pel...@gm... 
> <mailto:pel...@gm...>> 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.

Mike

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com