I've tested on PyPy 6.0.0 (3.5.3), CPython 3.6.6 and macOS High Sierra 10.13.6
@jklymak, please review

OK< that's interesting - not claiming to be a mac-app expert at all.

The verify_framework() check was to verify that we are using a framework python on OSX. If we are going to allow non-framework pythons, then we can just get rid of that whole subroutine, in which case your new code would go in lazy_init().

The reason for the check was weird interactions between the REPL and the GUI, as in #665. If I don't include your new line, then I still get those errors. If I do include your new line I can't reproduce the errors noted in #665. I'm not sure if there aren't other errors, but my quick testing indicates your change works.

I'm not an expert on Mac GUIs and don't even use the macosx backend, so I'm happy to defer to others as to whether this suggested change is an issue or not. I just got involved to try and fix the backend choosing issues. If we could get rid of the framework/non-framwork issues it'd sure make our lives a lot easier.

But I suggest the change go in lazy_init() and we get rid of verify_framework if there is agreement that this is the right thing to do.

ping @jenshnielsen who is the most recent active dev who seems to grok this stuff.

@jklymak Unfortunately I am not much more of an expert and at the moment not even a mac user. We did indeed disable it due to the issues in #665, If this makes it possible to work without being a framework build we should go for it.

@jklymak Unfortunately I am not much more of an expert and at the moment not even a mac user. We did indeed disable it due to the issues in #665, If this makes it possible to work without being a framework build we should go for it.

I can't reproduce loosing plot window focus (#665) on CPython 3.6 and PyPy 6.0.0 with this PR.

Seems like we need to leave verify_framework cause this fix is only for the newer macOS (>=10.6)

Fair enough, but maybe only invoke verify_framework in that case...

The point being that we don't have to start the event loop as early if we don't do this until lazy_init (for OSX >= 10.6)

The point being that we don't have to start the event loop as early if we don't do this until lazy_init (for OSX >= 10.6)

Make sense... Done.

This is kind of a game-changer if we don't have to steer OS X users to the framework build all the time. Thanks a lot, I dont' really understand what the Activation Policy flags mean, so justr assumed it was the way it was because.

It would be good if someone who knows how to embed Matplotlib in a Mac GUI would write a small test GUI and make sure this doesn't break it somehow.

This is kind of a game-changer if we don't have to steer OS X users to the framework build all the time. Thanks a lot, I dont' really understand what the Activation Policy flags mean, so justr assumed it was the way it was because.

It just tells OS how to display the App.
From Apple Developer documentation:
https://developer.apple.com/documentation/appkit/nsapplicationactivationpolicy/nsapplicationactivationpolicyregular

From stackoverflow:
https://stackoverflow.com/questions/16125371/setactivationpolicy-to-regular-and-openwindow#20388602

If you want you can try NSApplicationActivationPolicyAccessory instead of NSApplicationActivationPolicyRegular — it works the same except it has no dock icon (which is somewhat less comfortable to me).

I'm not an Apple developer in any sense (it actually was the first time I have to look at the Objective C code). But I'm really want to make the Matplotlib working with PyPy :)

Tested on CPython 3.6.6 and PyPy 6.0.0 (3.5.3) both from MacPorts. Both work.

@jenshnielsen, please approve

@dopplershift or @dstansby : do either of you know of any bad interactions this might have?

Tread very carefully here. I seem to remember once upon a time I was convinced things worked without a framework Python, but that hard check was added for a reason.

One thing I do remember was that when I wasn't using a framework build, things like closing figure windows no longer work.

I tested the bad behaviour I knew of

• windows don’t respond to cmd-w
• GUI would never accept keyboard input

And those are both OK

I’m not sure it’s the end of the world to change this. Worst case scenario folks start using the non-framework build and we get some bug reports and ask them to use the framework build. I don’t think we will actually break anyone’s code.

OTOH if anyone remembers other bad interactions we should definitely check.

Ping @mdehoon as you seem to have some expertise.

This seems reasonable, but pushing to 3.1 (targeted for early next year).

@tacaswell, @jklymak, @jenshnielsen
Hi, everybody! Didn't we forget to merge it?

No, it needs a second review (we do two reviews to merge)...

Could you invite here those, that can make the second approvement?

For the record, that was with Python 3.6.6 (conda-forge) and MacOS 10.14.1.