[haiku-appserver] Re: input issues

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 21 Apr 2005 10:35:41 +0200 CEST

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 :-)


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.

Other related posts: