[haiku-appserver] Re: GetMouse()

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sat, 28 May 2005 20:13:27 +0200 CEST

Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote:
> Axel D=F6rfler wrote:
> > However, this can still be problematic as you potentially block the 
> > thread the same time you'd do from its own thread, we might still 
> > need 
> > to change it back (ie. change UpdateIfNeeded() to process these 
> > messages from another thread).
>       I'm afraid I don't understand what you mean...

As long as the looper is locked, it cannot process any messages, and 
therefore doesn't get updated, even if running in another thread - was 
that clearer=3F

> > But we can postpone this decision when actual problems arise, I 
> > guess; 
> > after all, BView::GetMouse() is probably only rarely called this 
> > way 
> > (although I could imagine that ported single-threaded apps would do 
> > it 
> > this way).
>       I think if GetMouse() is called from another thread, it just 
> queries
> the app=5Fserver from mouse coords. We have to check.

We should check that, although I don't think it works this way. The 
disassembly shows no evidence whatsoever (Dano, though) :-)

> > It's not even that complicated; if GetMouse() wouldn't catch 
> > B=3D5FMOUSE=3D5FDOWN events, it could never tell you when the user 
> > pressed 
> > another mouse button. That's certainly not what you'd want or 
> > expect.
>       Um... don't think so.
>       It would get the state of mouse buttons from the newest
> B=5FMOUSE=5FMOVED message. It reads "buttons" field.
>       And GetMouse() certainly doesn't tell you if the the user pressed
> another mouse button, it just tells you the latest state of mouse 
> buttons
> (one could have pressed and released a button in the mean-time).

1) GetMouse() is not supposed to give you the most recent message, but 
the oldest one in the queue
2) you can press and release mouse buttons without moving the mouse at 

> >>    Damn, I was trying to avoid doing that on the server side. 
> >>Apparently I 
> >>cannot escape this. I just wanted to have RootLayer's thread do as 
> >>little as possible, and do the rest of processing in other threads.
> > There would be one hack around that, the "where" field could be 
> > added 
> > to those messages before DispatchMessage() is called. But of 
> > course, 
> > that would have to be done always before you call that method 
> > (app=3D5Fserver could add a "screen=3D5Fwhere" field only then).
>       Yes... but it's ugly.
>       We'll do it in the server.

Okay, that's nicer indeed :-)

> > [event mask]
> > I have definitely no pressure there, I just wanted to mention it. 
> > Sure, 
> > it would be nice if you could fix it :-)
>       I think I have a quick fix. But that would be for 
> SetMouseEventMask()
> only. SetEventMask() will take a little more time.
>       I guess you need SetMouseEventMask() more, than SetEventMask(), 
> isn't it=3F

For that particular problem I saw, only SetMouseEventMask() is needed, 


Other related posts: