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
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
