How do you execute an OS X application (bundle) from Python?
me at privacy.net
Fri Nov 5 14:00:25 CET 2004
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).
Never play leapfrog with a unicorn.
More information about the Python-list