How do you execute an OS X application (bundle) from Python?

[Alex Martelli]

Dan Sommers <me at privacy.net> wrote:
   ...
> > "Spawning an external editor and waiting until the user is done using it
> > before proceeding" is an important architectural pattern (well examined
> > and analyzed in Raymond's "Art of Unix Programming", like many others).
> 
> Tty based Unix programs, yes; modern GUIs, no.  The usual parent-child
> relationship between application and editor is nowhere to be found these
> days.  Consider this scenario:

And yet, as a user, I vastly prefer those apps which, even if they have
their own GUIs, still let me edit stuff with my text-editor of choice,
say GVIM or Emacs, even when that editor, too, is a "modern GUI" app.
Yes, the process relationship may be murkier and therefore it can be
harder for the driving app to find out when the user is done editing
that file -- nevertheless, I can be SO much more productive with my
editor of choice than with whatever the driving app may choose to use
for text editing, that, as a user, I still consider that important.

>     1.  The application requests that Mac OS launch TextEdit and that
>         TextEdit edit the given file.
> 
>         TextEdit starts (or maybe TextEdit was already running) and
>         opens the document (or maybe the document was already open).
>         The appliction neither knows nor cares about either of those
>         details.
> 
>     2.  In any event (pun intended), the user edits the file, and maybe
>         even saves it once or twice just in case there's a crash, and
>         ponders the configuration before committing to it.
> 
>     3.  The user is distracted by, for example, Software Update (which
>         is very annoying, but it happens), and attends to that matter.
>         It could be a printer failure, or new email, or anything that
>         causes the user to start working in another application.
> 
>     4.  While Software Update is thrashing, the user remembers that the
>         configuration file is open but has already been saved, and
>         closes it by clicking on its window's dimmed close button.
>         TextEdit processes the event and closes the window without
>         further ado.
> 
> At which point does the application know that the user is finished
> editing the file?

The application should somehow be notified after point (4); any earlier
time would be inappropriate.

> With vi-as-a-child-of-the-application, even if the user spawns a
> subshell (and, for that matter, an entire nested X server/session), the
> termination of vi is still a well-defined.

As is the closing of a document by an app.  Whether another app has an
easy time or a hard time finding out is another issue, connected with
how well designed is the OS/desktop manager/window manager/... that is
responsible for coordinating communication between the apps.


> > Ideally it should be the external editor of choice for the user;
> > foisting vi on poor innocent machistas just because it's easy to wait
> > for THAT and hard to wait for TextEdit would seem mean;-)...
> 
> Speaking as a long time Unix hacker *and* long time Mac user, Forcing
> machistas to use a text editor instead of a GUI to edit config files
> would seem mean.  ;-)

Speaking as a long time Unix lover who's reasonably recently falled in
love with the Mac, just like _many_ others these days, *because* MacOSX
*is* now a Unix -- I'd rather keep the option of editing textfiles with
a text editor, not be forced to use somebody else's idea of how that
particular file should be edited, thankyouverymuch.  It's exactly the
concept that I _couldn't_ work the way I liked, with a commandline and
text editors, that kept my interest in the Mac hovering around 0 for
about 19 years.  Then, suddenly, I found out that it had become an
excellent BSD *plus* a neat GUI layer -- now, *that* was interesting!

Developers of Mac apps, mostly -- and therefore developers of
infrastructure that runs on Macs to help apps -- apparently haven't yet
caught on to this reasonably-new bunch of users, me included, who see
MacOSX as just what it IS today -- a BSD with a neat GUI on top (and a
Mach underneath, sure, but that's hardly ever relevant;-).  Fine, I
guess we'll stick with fink and darwinports and the like.  But (unless
I'm being paid for it) I'm not going to write an application that I
would never want to use myself.  So, if the only way to shell out to an
editor is to write commandline apps instead of GUIs, and use /usr/bin/vi
(which IS, after all, one editor Apple that is bundling, to which we can
easily shell out), then that's going to be what we do -- until and
unless shelling out to TextEdit or BBEdit or whatever is just as easy.

Sure, Windows and Linux DEs make it easier because they do preserve the
traditional process relationship -- I can start another process running
(whatever program, GUI or not) and wait for that process to terminate,
rather than having to reuse an existing process that already happens to
be running that program.  But, since the event I need is "done
processing that specific file", I should be able to wait for that, just
as easily as I can wait for process termination.


Alex