Skip to content

FIX: macosx framework check #11850

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 19, 2018

Conversation

jklymak
Copy link
Member

@jklymak jklymak commented Aug 13, 2018

PR Summary

Closes #11846

In the macosx backend, verify_framework now (post #11600) gets called before the app gets started, so the checks for the framework always fail. This PR, at the suggestion of @anntzer simply uses the old pre 10.6 checks. Not sure this is the correct solution versus moving verify_framework to a point after the app has started, but it does work on my machine (10.13.6); using framework python (pythonw) works, using non-framework python (python) gives the appropriate error.

This PR moves the verify_framework check into lazy_init, where the app is started, and passes success or failure up a level.

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@jklymak jklymak added Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. GUI: MacOSX labels Aug 13, 2018
@jklymak jklymak added this to the v3.0 milestone Aug 13, 2018
@jklymak
Copy link
Member Author

jklymak commented Aug 13, 2018

Attn @jenshnielsen...

@anntzer
Copy link
Contributor

anntzer commented Aug 13, 2018

Happy with the change, but I'm not claiming any expertise on the topic.

@jklymak jklymak force-pushed the fix-macosx-framwork-check branch from 059b9bb to 1086de7 Compare August 13, 2018 20:35
@jklymak
Copy link
Member Author

jklymak commented Aug 13, 2018

OK, figured out how to pass the failure up the line. Now lazy_init calles check_framework after the app has started...

@jklymak jklymak requested a review from anntzer August 13, 2018 20:36
@jklymak
Copy link
Member Author

jklymak commented Aug 13, 2018

... and doesnt' depend on the deprecated calls...

@anntzer
Copy link
Contributor

anntzer commented Aug 13, 2018

The problem is that for backend fallback to correctly work, we need importing the backend to fail with ImportError; backend fallback (at least as it is written right now) doesn't work with later failures.
So I think right now using the deprecated Carbon API remains the best solution that we know of.

@jklymak
Copy link
Member Author

jklymak commented Aug 13, 2018

OK - see my comment on gitter - it turns out that not having the Framework installed (pythonw) doesn't stop the GUI from working FAICT, it just is slightly suboptimal in that the GUI doesn't have a dock icon, so it can get burried under other windows. To my taste that isnt' something to Error over, but rather we could/should throw a warning.

@anntzer
Copy link
Contributor

anntzer commented Aug 13, 2018

Well, you have to ask those who put in the check to start with (#1613 and other PRs).
(Let's keep the discussion here rather than on gitter.)

@jklymak
Copy link
Member Author

jklymak commented Aug 13, 2018

Ah, OK, the issue is #665; if you open the save dialog you can't get typing focus in the dialog box. I'm 50/50 still if that requires us to error or warn, but it can be said to be not fully functional.

@jenshnielsen
Copy link
Member

@jklymak Afaik we put this in because we got so many errors and spent so much time tracking down why the gui was not working. With pyqt5 and wxpython being pip installable now it seems easier for users to switch to a functioning backend rather than using a semi broken one so I am mildly in favor of erroring out but warnings are fine with me too.

@anntzer
Copy link
Contributor

anntzer commented Aug 14, 2018

OK, let's try something else.
In the pre-OSX10.6 code, only GetCurrentProcess and SetFrontProcess are deprecated (https://developer.apple.com/documentation/applicationservices/1501115-getcurrentprocess?language=occ); CGMainDisplayID is not (https://developer.apple.com/documentation/coregraphics/1455620-cgmaindisplayid). Would we be lucky enough to have CGMainDisplayID() return 0 on non-framework and nonzero on framework builds, in which case that'd be a way to check for frameworkness?

Copy link
Contributor

@anntzer anntzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As in comments: raising ImportError should occur when importing the module, not when trying to construct the objects.

@jklymak jklymak force-pushed the fix-macosx-framwork-check branch from 1086de7 to db64c09 Compare August 14, 2018 20:31
@jklymak
Copy link
Member Author

jklymak commented Aug 14, 2018

Would we be lucky enough to have CGMainDisplayID() return 0 on non-framework and nonzero on framework builds,

Nope, that doesn't work. Newest push just uses the deprecated methods at import.

@anntzer anntzer dismissed their stale review August 14, 2018 20:47

Comments handled.

@tacaswell
Copy link
Member

Merging this as it un-breaks osx for now (and pushing the reckoning of using deprecated APIs to future us).

The OSX backend is now agg based like the others (rather than an alternate rendering path) and presumably should also be made to play nice with cairo. The biggest advantage of the OSX backend over tk/wx is that it support hi-dpi. The biggest advantage over Qt is that it is no extra dependencies (on macs).

@tacaswell tacaswell merged commit f1b64ad into matplotlib:master Aug 19, 2018
lumberbot-app bot pushed a commit that referenced this pull request Aug 19, 2018
QuLogic added a commit that referenced this pull request Aug 19, 2018
@jklymak jklymak deleted the fix-macosx-framwork-check branch October 19, 2018 20:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GUI: MacOSX Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

macosx backend won't load
4 participants