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

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

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 <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.

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