[Pythonmac-SIG] What does it take to run a GUI app?

[Chris Barker]

Thank Ned,


> Anaconda is currently built with the old python / pythonw dichotomy.

>
> On vanilla OS X python builds, there is no difference between python and
> pythonw; that's been the case going back many years.


exactly -- I was quite surprised when i ran into this with Anaconda -- I
had totally forgotten about pythonw -- and the goal is to let us all
continue to forget about it.

>  In fact, as of
>
3.4, we no longer make the pythonw* symlinks.
>

Another reason why we really don't  want to use that...
 > pythonw, on the other hand, is a shell script that re-directs to a python
> that is inside a hand-built application bundle:
>
> #!/bin/bash
> export
>
PYTHONEXECUTABLE=/Users/chris.barker/PythonStuff/Anaconda/anaconda/bin/python
>
/Users/chris.barker/PythonStuff/Anaconda/anaconda/python.app/Contents/MacOS/py
> thon
> $@

This is something supplied by Anaconda?
>

yup.


> > I know that this has been solved for years in the python.org installer.
> So
> > how is that done?
>
>

> A framework build, like used in the python.org installer, creates a
> Python.app app bundle within the framework:
>
> /Library/Frameworks/Python.framework/Versions/x.y/Resources/Python.app
>
>
OK -- this is more or less what Anaconda does, though without the whole
Framework, just the app bundle.


>   The tricky part is
> that a bootstrap executable, built from the somewhat confusingly named
> pythonw.c (http://hg.python.org/cpython/file/3.4/Mac/Tools/pythonw.c),
> is what is actually installed into the framework bin directory and
> symlinked to from /usr/local/bin/ or wherever.  The bootstrap
> executable's job is to essentially transparently launch Python.app from
> the command line.


ah hah! that is what Anaconda's pythonw script does, but not as well. This
is what we've been looking for.


>   That is, when you type:
>
> /usr/local/bin/pythonx.x
> or
> /Library/Frameworks/Python.framework/Versions/3.4/bin/pythonx.y
>
> you are first executing the bootstrap executable and it then spawns or
> execs the real interpreter executable under Python.app so that Python
> runs as a app that can be a gui process.
>

Is there any downside to this? a measurable amount of overhead?


> Now, these days, most of the time you probably don't need to be a gui
> process, especially since we no longer support the obsolete deprecated
> Mac Carbon-based API wrapper functions in the standard library.  And if
> you are building you own gui app, presumably you can use py2app to
> produce your app as its own app bundle.
>

you can. but you sure don't want to from the start of your development
process. And there are hybrid command-line GuI apps like iPython or
anything that wants to pop up, say, a matplotlib graph. So we do need a
command line python that can run a GUI.


> I'm not familiar with wxPython at all but, if it doesn't already, it
> might be able to take the approach Tcl/Tk does on OS X.  Tk seems to do
> some tricks to make itself a gui process and it also has an embedded
> Wish.app at least when Tk is built as a framework.  But I haven't looked
> closely at it.  The relevant code in the the Tk file
> macosx/tkMacOSXInit.c.
>
>
well, _maybe_ the alpha wx project, "Phoenix" could do this, but the legacy
version will be around for a while. And it looks like folks are having
problems with native Cocoa GUIs as well (at least with matplotlib, that I
know of)



> > Anaconda doesn't seem to want to make their python a proper framework
> build
> > -- don't know why not -- would there be any downside? But is it possible
> to
> > build the python executable so it can access the GUI system without
> > structuring their whole python install?
>
> One issue might be that the current framework builds are meant to be
> installed at a fixed path, by default /Library/Frameworks.  You can
> change that at build time but we don't support changing it at install or
> run time.
>

well Anaconda would need to be able to re-locate, that's kind of the point
-- so probably why they didn't just grab that build to begin with. Not that
they couldn't make a re-locatable Framework. But problem at hand is about
the app bundle and start up executable, not the Framework anyway.

Without knowing more, I'd look to solving the issue in wx rather than
> Python since it might affect other users as well.


well, this isn't jsut a wx problem. IT seems beter to me to solve it at teh
python level, rather than the separate GUI level.



> The Python framework
> GUI stuff is quite old and hasn't really been closely examined in a long
> time.  There *might* be better ways to do it today.
>

There might -- but if it ain't broke.... thanks for pointing us to the
relevant code -- if the Anaconda folks want to fix this, that looks like a
good place to start.

Or if anyone has any ideas for a better way... Maybe whatever tk does to
trick the system?

Thanks again,

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20140822/c12ab4b9/attachment-0001.html>