bugGNUstep - Bugs: bug #6056, Duplicate application launching

Group
 
 

bug #6056: Duplicate application launching

Submitter:  Stefan Urbanek <stefanu>
Submitted:  Sun 19 Oct 2003 07:08:37 PM UTC
   
 
Category:  Gui/AppKit Severity:  2 - Minor
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  alexm
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 05 Dec 2005 07:54:36 PM UTC, comment #15: 

I've added support for the NSUseRunningCopy user default as suggested by David.
That makes the behavior (I think) the same as MacOS-X, with renaming to use another port (and thus permitting duplicate copies) the standard behavior, but activation of the existing copy (and termination of the new copy) the behavior when the new default is turned on.

I'm marking the bug as closed/fixed since the original report was incorrect (in the sense that the requested behavior is neither MacOS-X/OPENSTEP compatible nor generally agreed to be superior to the MacOS-X/OPENSTEP behavior) and I beleive all issues are now resolved.

Richard Frith-Macdonald <CaS>
Group Member
Sat 03 Dec 2005 09:29:05 PM UTC, comment #14: 

I rechecked and now am getting the correct behavior, on Linux 2.6 / Xfree 4.3 gnustep CVS 2005/11.  I was experiencing the "terminate other or quit self on rename" problem for a few months, but I think what was going on was that I needed to do a more thorough cleaning out of my installed system after all of the recent runtime path/config changes.

I still don't understand the rationale for terminating the other running instance if 'continue' is selected; from an end-user perspective it would seem simpler to remove 'rename' and have 'continue' do what 'rename' does now (and simpler still just to follow OS X's behavior)..

Adrian Robert <arobert>
Group Member
Sat 03 Dec 2005 08:04:16 AM UTC, comment #13: 

With regard to the 'current status of this bug' ... the comments do not reflect my experience at all, and I wonder what version of the code is meant by 'current' ...

When I try using openapp to open an app which is already running, it does start a new copy.

When I do this, I get a panel asking to rename/abort/continue, not just abort/continue.

If I select 'rename' at that point, I get two running copies of the app.
If I select 'continue' at that point, the old app is terminated and the new one continues.
If I select 'abort' at  that point, the nerw app terminates and the old one continues.

Looks pretty good to me ... the only thing I might want to change is to have some mechanism to specify one of those three actions in advance, so that the stage of displaying the panel can be skipped.

Richard Frith-Macdonald <CaS>
Group Member
Wed 30 Nov 2005 02:40:08 AM UTC, comment #12: 

The current status of this bug is as follows: if you open with openapp, it does not attempt to start another copy, but the existing app is not switched to.  If you open from direct command line execution, you get the standard dialog about whether to abort or continue, but if you try to continue, the other running instance will be asked to quit.  If the user cancels this 'quit', the second copy will put up a second dialog saying it can't register under ANY name, and then gives up.

I agree with the previous comment here that says the whole 'abort / continue' dialog should just be dropped -- OS X lets you start multiple instances from the command line without complaining, and it can be useful for debugging, as well as in other special cases.  If this cannot be accomplished, the recently introduced behavior of trying to kill off the other instance should be removed.

Adrian Robert <arobert>
Group Member
Mon 27 Oct 2003 09:03:20 PM UTC, comment #11: 

IIRC, OPENSTEP 4.2 Enterprise (read  Windows) Apps did start and terminate themselves if the application was already running.  To prevent that there was an NSUseRunningCopy or something similar default that was used...let me check, ahh!:
http://www.toodarkpark.org/computers/objc/AppKit/Classes/NSApplication.html
see +useRunningCopyOfApplication.
Personnally I found it annoying.  But it should be considered.  In fact I'm not sure if the reason for this 'feature' may have been complicated NSWorkspace/Explorer interaction.  Yet if we did add the feature we should use the same default name.

David Ayers <ayers>
Group Member
Mon 27 Oct 2003 08:48:06 PM UTC, comment #10: 


> confusing to users ... ie it would be the introduction of a bug.


Well ... from a lot of peoples point of view anyway.

Of course, if we have a majority of users wanting this behavior, it makes sense to change and be incompatibile with MacOS-X ... but I think if we do that, the behavior should at least be selectable by the GSMacOSXCompatible user default at runtime.

Richard Frith-Macdonald <CaS>
Group Member
Mon 27 Oct 2003 08:30:14 PM UTC, comment #9: 

If someone runs an application from the command line, it should start up a new copy of the application.  That is what the NextStep, OPENSTEP, MacOS-X, and normal unix convention is.  Having default behavior be to exit if a copy of the application is already running would be inconsistent and confusing to users ... ie it would be the introduction of a bug.

Richard Frith-Macdonald <CaS>
Group Member
Mon 27 Oct 2003 08:22:47 PM UTC, comment #8: 

I just looked at Apples latest NSWorkspace documentation, and see that, as of MacOS 10.3 they have a new method to launch applications, which provides more fine control over the way that the application is launched ... perhaps we should be implementing that?

Richard Frith-Macdonald <CaS>
Group Member
Mon 27 Oct 2003 08:10:04 PM UTC, comment #7: 

I think, that this should be fixed in application startup, not in NSWorkspace. What if someone runs the application from command line?

To allow multiple launches, there should be some commandline argument, like --GSAllowMultipleInstances. If the argument is not specified, application will contact its running instance and will exit immediately.

Alert should be removed, because we decide whether to run it or not by using the argument.

Stefan Urbanek <stefanu>
Group Member
Mon 27 Oct 2003 08:02:15 PM UTC, comment #6: 

I just looked at Apples latest NSWorkspace documentation, and see that, as of MacOS 10.3 they have a new method to launch applications, which provides more fine control over the way that the application is launched ... perhaps we should be implementing that?

Richard Frith-Macdonald <CaS>
Group Member
Mon 27 Oct 2003 07:52:18 PM UTC, comment #5: 

I'm still confused about what the problem is supposed to be.
When I use the NSWorkspace method to launch an application which is already running, it does not attempt to launch a duplicate copy (though neither does it make the existing copy active ... I think it should - a simple message to the running application to activate it should fix this).

When I launch a new copy by directly excuting it (rather than via the NSWorkspace API) it does launch a duplicate copy ... and I think that's correct behavior ... certainly it's what NeXT/QApple do too, and makes sense to me ... I can't see a reason for preventing people having multiple copies of an app runing if they want to.

The alert panel raised when launching duplicate copies is a hack we added many years ago, before the NSWorkspace code was implemented, and before gopen and GWorkspace were available to allow users to launch apps using the NSWorkspace API.  I think this could probably be removed now ... so when you launch duplicate apps intentionally, you should not longer get a warning, and the new copy of the app should just start up normally.

So ... I see two things to be fixed:
a) activate running app if we call the api to launch it.
b) remove the alert pan el when multiple copies are run.

but I don't actually know of any occasions where we get duplicate copies of an app launchd and we shouldn't.

Richard Frith-Macdonald <CaS>
Group Member
Mon 27 Oct 2003 07:04:36 PM UTC, comment #4: 

Beeing there, you could take a look also at the bug #4410 that is probably correlated :-)

Enrico Sersale <esersale>
Group Member
Mon 27 Oct 2003 06:46:31 PM UTC, comment #3: 

Matt Rice and I have been looking at the duplication issue too. We have a patch that fixes it, and currently I'm Thinking Really Hard about whether it's the Right Thing.

Alexander Malmberg <alexm>
Group Member
Sat 25 Oct 2003 12:00:45 PM UTC, comment #2: 

Alex M. applied something in cvs for me which I believe should
fix this.
where connecting to the running application would fail in some
cases (see ChangeLog)

though i'm not seeing the ordering front of the clicked on application and haven't tried the keyboard modifier, I'm guessing those cases should be handled in GWorkspace

matt rice <ratmice>
Group Member
Fri 24 Oct 2003 07:13:17 AM UTC, comment #1: 

I'm not sure what context you are referring to (ie what application launching mechanism you are talking about).

Certainly I like the behavior the NeXT workspace used to haver, where double clicking on an application in the workspace would simply bring the app windows to the front if the app was already running, but a keyboard modifier would force the launch of another copy of the application.
I see that as an issue for the workspace manager ...
If it uses the NSWorkspace method launchApplication:shoiwIcon:autolaunche: the behavior should be the one we like.  Are you saying that there are circumstances where this method does not work properly?
Or are you talking about some other situation entirely?


Richard Frith-Macdonald <CaS>
Group Member
Sun 19 Oct 2003 07:08:37 PM UTC, original submission:  

If I launch an application, that is already running, i get an alert panel asking me about renaming, ignoring or aborting. I would expect that the existing application instance will be activated instead. So the behaviour should be: If there is already running application, activate it, if there is not, launch it.

Btw. are there any situations, where one would like to have two instances of one application open? How are they compared to the usual situations?

From the point of user, I consider this to be a bug. Moreover, it is another additional confusion.

Stefan Urbanek <stefanu>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-12-05 CaS StatusNone Fixed
    Open/ClosedOpen Closed
2003-10-27 alexm Assigned toNone None

Back to the top

Powered by Savane 3.13-758e.
Corresponding source code