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

[Dan Sommers]

On Fri, 5 Nov 2004 13:35:31 +0100,
aleaxit at yahoo.com (Alex Martelli) wrote:

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

Agreed.  My editor of choice these days is emacsclient.

[ typical multiple-user-GUI-application interaction scenario snipped ]

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

Well, yes, but does TextEdit and/or Mac OS provide that functionality?
Does KDE or GNOME?  Those are honest questions; I haven't written a
native Mac application since OS9, and I've never written a KDE- or
GNOME- aware application.

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

Let me try it this way:  Is a "text file" (or a "sequence of bytes or
characters"), edited by hand with a text editor, the best interface to
configuration information?  I must admit that I'm impressed by the
amount of point-and-click configuration I can do with KDE; I never have
to look at a config *file* unless I want to (but I can look at them if
there's a problem, which seems to be the best of both worlds).

Yes, some configurations are complex, and I *detest* the number of mouse
clicks required by some of the associated interfaces (I'd much rather
type [part of] the name of a directory than "navigate" a bunch of little
disclosure triangles up and down the file system).  But I now believe
that it's only a matter of time before we discover the right GUI
paradigms to edit even these sorts of things (although I never used to
think this way).

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

There's a command line BBEdit wrapper somewhere; Bare Bones would seem a
likely candidate to provide the second half of shelling out to them
(i.e., letting the parent app know when the user closes the file's
window in BBEdit).

> Alex

Regards,
Dan

-- 
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.