[haiku-appserver] Re: GetMouse()

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 23 May 2005 17:36:31 +0300

Axel Dörfler wrote:
>>      Well... yes, there's no real reason to do that. However, to me,
>>it doesn't sound right to execute the update process from another 
>>than BWindow's one - that's the main reason for this thread isn't 
> Yes, you might be right with this one. As you might have already seen, 
> UpdateIfNeeded() only processes the =5FUPDATE=5F messages when it was 
> called from the looper's thread.

        I saw.

> 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...

> 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_server from mouse coords. We have to check.

> It's not even that complicated; if GetMouse() wouldn't catch 
> B=5FMOUSE=5FDOWN 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_MOUSE_MOVED 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).

>>      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=5Fserver could add a "screen=5Fwhere" field only then).

        Yes... but it's ugly.
        We'll do it in the server.

> [event mask]
>>      As Stephan asked if someone wants to to something about this issue, 
>>can continue doing it and make the event mask stuff work. 
>>I can't do it in this weekend because I'm out of town. If you can 
>>until Monday...
> 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 


Other related posts: