bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #4066] NSWorkspace launchApplicaion: misbehaved


From: Richard Frith-Macdonald
Subject: Re: [bug #4066] NSWorkspace launchApplicaion: misbehaved
Date: Sun, 22 Jun 2003 12:19:44 +0100


On Sunday, June 22, 2003, at 11:39  am, nobody@savannah.gnu.org wrote:


=================== BUG #4066: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4066&group_id=99

Changes by: David Ayers <d.ayers@inode.at>
Date: Sun 06/22/2003 at 12:39 (Europe/Vienna)

------------------ Additional Follow-up Comments ---------------------------- I think the price on performance (time waiting on an app to finish all of its initialization) would be to high for the avarage case. Maybe we could augment the API with a method, that actually waits?

In order to implement a waiting API, we would have to pause in a run loop waiting for the app to notify us it had started up. This would be no more efficient than having the user code do it, and would just bloat the API with another (almost never used) method.

Or send a distributed notification before/after posting appDidFinishLaunching:?

This is what the system currently does ... and as far as I understand it, how it's supposed to work.

The MacOS-X documentation is a bit misleading in that it says that the -launchApplication: method sends one notification 'before this method begins' and one 'when the operation is complete' ... which (to me ) implies that it always sends the notifications.

In fact the -launchApplication: sends a notification when it is about to launch the child, then it performs the actual launch, and returns YES The child application sends a notification when it completes startup. If the child was already running, no notifications are sent. If the child was launched but fails to start properly, the first notification is sent but the second is not.

For sure, if you want to launch an application, and wait, blocking all further actions, until it has started and is ready to talk to you, this mechanism is a little clumsy, but OpenStep is designed largely around event driven programming, and you are really expected to be familiar with using notifications to handle events when they occur rather than blocking ... so within the context of OpenStep programming, it seems like a natural mechanism to me.

Of course, the fact that a child applications sends a notification to say it has launched, does not mean that you can connect to it ... it may have chosen not to listen to you, or may die again immediately etc. So your code needs to try connecting to it and handle failures in whatever way you think is best.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]