gnustep-dev
[Top][All Lists]
Advanced

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

Re: opening problems with GWorkspace


From: Wolfgang Lux
Subject: Re: opening problems with GWorkspace
Date: Sat, 24 Apr 2010 14:55:16 +0200

Fred Kiefer wrote:

Am 23.04.2010 17:14, schrieb Wolfgang Lux:
Incidentally, I noticed during debugging that GNUstep applications do
not respond to DO messages while in a modal dialog loop. This means that if the user or a background application attempts to connect to a running
application while that application presents a modal dialog, a new
instance of the application is launched. If your are using GWorkspace,
just put in it into a state where it presents a modal dialog (in the
default configuration move a file do a different folder or to the
trash), then switch to a terminal and call gopen. After a short delay
when the timeout of [conn rootProxy] has expired a new instance of
GWorkspace is started. If your are not using GWorkspace, you can use Ink
instead. Open its open panel and then use gopen -a Ink to open a rtf
document. Again, after a short delay this will start a new instance of Ink. Both behaviors are really annoying. Of course, it is quite unlikely that a user will gopen a document while its application is presenting a
modal dialog, but this situation could easily arise with background
tools using GWorkspace to launch applications or present documents (or
just check the list of running applications!).

This sounds like a very annoying bug to me. And even though we probably
have had it for a long time we should try to fix it now that we know
about it.
Does this mean that DO messages aren't handled at the run loop mode that
modal windows run in? I just don't understand enough of that area to
suggest a fix.

I don't have a fix either, but I think that part of the problem is that NSWorkspace's _connectApplication: simply assumes that the application is not running when a timeout (or any other DO error for that matter) occurs while asking for the connection's root proxy. IMO, if NSWorkspace can connect the application it should assume that the application is running and if a timeout occurs, it should report the timeout and maybe offer the user a chance to kill the other application in case it is really stuck in a infinite loop. In addition, setting the timeout to the unusually small value of 5 seconds is probably not a good idea either.

Wolfgang






reply via email to

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