Re: GsTcpPort (NSDefaultRunLoopMode / _handleWindowNeedsDispaly:)

[David Ayers]

Thanks Richard,

I am definatly not aware of all the implications this would have, and I agree 
that the temporary disabling of the View's display seems like an appealing 
suggestion. I actually went as far as trying to replace the entire 
_handleWindowNeedsDisplay mechanism because I am (still) convinced, that it is 
insufficient to handle state dependant display. (I actually have something 
working at home and I'll be glad to post it on Saturday.)

Yet when I tried to verify my changes against OPENSTEP, I realized, that the 
current mechanism follows this implementation very closely. All the way down to 
-rootProxy calling something which will eventually rerun the runloop just like 
in GNUstep except in a different mode. So I decided to aim for compatibility 
and returned to that route.

A couple of observations: An NSTextFieldPoser implementing 
-(void)selectText:(id)sender
{
  [super selectText:sender];
  [[NSRunLoop currentRunLoop] runUntilDate:[NSDate date]];
}
causes the same flashing in OPENSTEP as I see in my modified version of 
GNUstep. So there is no disabling/enabling taking place.

yet the following implementation:
-(void)selectText:(id)sender
{
  [super selectText:sender];
  [NSConnection rootProxyForConnectionWithRegisteredName:@"TestServer" 
host:@"*"];
}
doesn't flash (as explaned above, this is because the runloop is rerun in 
NSConnectionReplyMode).

OK, my main Problem with the enable/disable apporach is the fact, that it's not 
the views "fault" (or rather reponsibility). Any view or other object 
interacting with the pasteboard server will have same problem, and all would 
require this guarding of display.

It is NSPasteboard's attempt to allways get the "current" rootProxy of the 
server. Normal DO messages to a proxy *DO* get sent in NSConnectionReplayMode, 
and the don't provoke display. It's just during the reoccuring attempt to get 
the current rootProxy, that GNUstep (unlike openstep) runs in 
NSDefaultRunLoopMode. Now maybe we could make it it's (NSPasteboard) 
responsibility to notify that the runloop is about to run in 
NSDefaultRunLoopMode by sending some method the App or posting some 
notification before and after. Yet I belive it should be the responsibility of 
the object accessing the rootProxy to "warn/unwarn" of the runloop being run in 
NSDefaultRunLoop mode. Then NSApp or the windows could provide for 
disable/enable display.

>
>In GNUstep, the libraries are carefully designed never to use threads -
>partly for portability (when this was first being written, a lot of systems
>did not have reliable threading), and partly so that, unless the application
>programmer specifically wants/needs them, you won't have threading and won't
>suffer the performance degradation caused by the locking they make 
>necessary.
>
>I think that MacOS-X sends DO messages in separate threads - so that the
>application is able to handle incoming messages while waiting for the send
>to complete.  

I can't verify any "other" event handling of OPENSTEP during the accessing of 
the rootProxy except that the RunLoop is running in NSConnectionReplayMode, 
i.e. the App is unresponsive at this time to UI-Events.

>This might lead to a slight difference in behavior as in GNUstep both 
>establishing
>a new connection, and sending a message to the connection will result in an
>iteration of the run loop in the default mode, while in MacOS-X they may 
>not.

Well I'm not against differences in behavior, then maybe we should go the 
"warn/unwarn" Notification route to allow core-frameworks and Apps to provide 
for this "Unexpected" (In the case of OPENSTEP Apps) run in 
NSDefaultRunLoopMode.

>So ... if you want to prevent this, you would have to change the code for 
>sending
>messages (like a message to the pasteboard server) to run in reply mode, not 
>just
>the code for establishing the connection.

The actual messages to a procy *ARE* sent in NSConnectionReplayMode, it's just 
the fact that NSPasteboard always "reestablishes" the connection be getting the 
current rootProxy. (see -_pbs).

>I'm not sure what the ramifications of this might be ... basically, the code is
>designed to *permit* the app to respond to events while making a DO call, and
>what you are aiming to do is to *prevent* the app from responding to events.

Well it's only not reponding to events of NSDefualtRunLoopMode, which is what 
OPENSTEP does. It will process events of NSConnectionReplyMode.

I'm not asking for an "immediate" change. Rather for further comments and maybe 
we can get to the bottom of this.

Thanx,
Dave