[haiku-appserver] Re: GetMouse()

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 19 May 2005 16:06:16 +0200 CEST

Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote:
> Axel D=F6rfler wrote:
> > I've worked a bit on GetMouse(), and I think it's now more or less 
> > correct.
>       You're not done yet. :-)

We'll see about that :-)

> - only BWindow's thread must be allowed to dispatch messages. (This
> method should just query app=5Fserver if called with checkMessageQueue 
> =3D true
> from another thread - IMO. We should check how R5 behaves on this 
> one.)

Nope, there is no reason for that.

> - you don't need to lock the message queue because you'll be in the
> context of BWindow's thread. At least ::task=5Flooper() doesn't do so,
> maybe it should.

task=5Flooper() doesn't need to do this because 
BMessageQueue::AddMessage() locks itself. However, we don't want the 
message queue to change while we're at it, so we lock it. Since 
GetMouse() (and probably other stuff, too) might change the queue from 
another thread, this is just what we have to do.

> - you don't need to iterate through the whole queue for =5FUPDATE=5F
> messages, there's a maximum of one present at a time.

Ah, okay, good to know.

> - BeBook says: "his function first looks in the message queue for
>   any pending reports of mouse-moved or mouse-up events" yet you 
> discard
> B=5FMOUSE=5FDOWN also. Why=3F

Because if you wouldn't get those, GetMouse() would not work correctly; 
the documentation is wrong here.

> - "where" field from any B=5FMOUSE=5F* message contains a point that's in
> screen coordinate system, conversion to local coords is needed.

I don't want to frighten you, but that's not compatible to R5 here. And 
since every application is allowed to peek into that message, I think 
we need to change that. That's probably why the app=5Fserver/input=5Fserver 
knows the target view in R5, too.

>       The rest is fine, thanks for your time. ;-)
> 
> Oh, one more thing...
>       owner->fLink->Attach<port=5Fid>(owner->fLink->GetReplyPort());
> needs to go. It's useless.

The one in GetMouse()=3F Sorry, you're wrong - when I remove it, nothing 
is working anymore, the whole app stands still after that. So much for 
defensive and robust programming :-/

> > It still doesn't work correctly, but this time it's probably the 
> > app=5Fserver's fault, as we only rarely get =5FUPDATE=5F messages.
>       Well, maybe with the above changes it will.

Yes, indeed, the coordinate change helped a lot :-)
It still looks very bad compared to R5 as well as the asynchronous 
version, but at least it's somewhat working now!

BTW: in asynchronous mode, when you press the mouse button over the 
button (playground app), and then release it somewhere else, the button 
still changes its status on mouse over (without a button pressed).
This doesn't happen under R5, so I guess our event mask stuff is not 
yet working correctly.

Bye,
   Axel.


Other related posts: