Re: Launching an App without NSWorkspace?
Re: Launching an App without NSWorkspace?
- Subject: Re: Launching an App without NSWorkspace?
- From: Douglas Davidson <email@hidden>
- Date: Thu, 5 Sep 2002 09:48:08 -0700
On Wednesday, September 4, 2002, at 08:39 PM, Kurt Revis wrote:
Very roughly: Calling system() will run a shell, which interprets the
text you give it, and then finds the 'open' command (assuming your
path isn't screwed up), and forks and exec's it. Open then needs to do
a bunch of work to initialize the Obj-C runtime and Cocoa, and then
calls into NSWorkspace, which then ... guess what ... probably does
just about the same Launch Services calls as the ones above. Why not
just do it directly?
Also, I think it's worth knowing about all the functionality available
in the system. There are some features in LaunchServices that you
can't get elsewhere. The original poster didn't give enough detail to
determine whether the Launch Services stuff would be useful for him,
or not.
The above is essentially correct, but I think it's worth giving a
summary of the system layers involved here.
In the case of a standard application launch--for example, when an app
is double-clicked in the Finder--the app is actually invoked (i.e.,
fork/exec'd) by a server process. This launches it as a process in a
certain standardized way.
The low-level programmatic interface to this functionality is Launch
Services. When Launch Services is asked to launch an app, or needs to
launch an app to open a document, it communicates with the server
process to request the launch. Launch Services has a wide variety of
options for precisely how to launch the app.
The Cocoa interface to Launch Services is NSWorkspace. This generally
exposes fewer options than Launch Services.
There is also a command-line interface to NSWorkspace, namely
/usr/bin/open. This is a command-line tool that links against the
AppKit and uses NSWorkspace to open documents and launch applications.
This points out that there is nothing in principle to prevent a
command-line tool from linking against the AppKit. However, there may
be situations in which you do not wish to do this.
It is also worth noting that an application is just an ordinary
executable (inside a bundle), and it can be invoked directly just like
any other executable. For example, typing
"/Applications/TextEdit.app/Contents/MacOS/TextEdit &" in a shell will
launch TextEdit. It will not do so in precisely the same standardized
way as the server process mentioned above, so this should not be used
for ordinary application launching, if you intend to achieve results
equivalent to double-clicking the app in the Finder. However, this can
be useful for cases in which you want direct control over the process,
e.g. to add command-line arguments.
If you were writing an executable that could link only against the
System framework, and needed to launch an application, you could
fork/exec the app directly, assuming you knew where it was located.
However, for a standard application launch, it would probably be better
to fork/exec /usr/bin/open with the -a argument, giving either the
app's name or its full path. (I would probably not use system() for
this in production code, because it adds a shell into the mix.) If the
executable could also link against the ApplicationServices framework,
then you could use Launch Services directly, and that would probably be
best. If the executable were written using Cocoa and could link only
against Foundation, then you could use NSTask to invoke /usr/bin/open
as previously mentioned. If the executable could also link against
AppKit, then it would probably be simplest to use NSWorkspace.
Douglas Davidson
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.