Hi there, Just trying to catch up on reading all these messages :-) Anyway, I have a comment I want to make about the cursor positioning being done in two ways simultanioulsy for 'user perception'. I might be totally off here, but I want to say it anyway just to be on the safe side: If you could get into a situation where a user moves the cursor (quickly) to a spot onscreen, and press a button there, while the app that should respond to that press still thinks the cursor is in an 'old' position, you are in trouble... Personally I hate asynchronous things (unless absolutely nessesary and/ or someone really knows what he/she is doing): using asynchronous things is creating an easy way to get messups. Anyway: if the error situation I am describing is not possible because of some reason I don't yet see, disregard this message please :-) Rudolf. Axel wrote: > > > > Instead, we should follow the path R5 has chosen, and use a > > > > direct handshake for updating the mouse cursor position only > > > > (note, the view transfer messages are still done over the > > > > standard > > > > message path, only the *visual* position update is not, since > > > > that's all that matters for perception). > > I don't understand... > > Are you talking about redirecting B_MOUSE_DOWN messages to > > the client BLooper? I remember sawing something like this in R5. > > (redirect_input_server() was called, I think) > I think :-) what he is saying is that there should be two paths for > updating the mouse position. One is a direct link from the > input_server > to the app_server, and it updates the cursor on screen without taking > any app_server client communication into account. The second path is Exactly, that's what I meant.