[haiku-appserver] Re: GetMouse()
- From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 19 May 2005 23:39:35 +0300
Axel DÃrfler wrote:
>>- 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.
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 thread
than BWindow's one - that's the main reason for this thread isn't it?.
>>- 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.
Ah, perfect.
> 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.
Yes, that's why I put those queue->Lock/Unlock() in GetMouse() in the
first place. Silly question from me on why lock is needed. :-P
>>- 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.
Well... I just asked. You who programmed BeOS a lot more than I did,
know better.
>>- "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.
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.
>> 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.
:-)) Sorry, my fault for not saying the whole story. If you add/remove
some data in any BPortLink message on one side (client/server) you need
to make sure you add/remove a line on the other side (server/client) in
order to read the new data.
> So much for defensive and robust programming :-/
BPortLink was not thought to be robust. It was thought to be as light
as possible. (Be did it almost identically - our method is a bit better
actually)
> 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.
Yep, exactly. I tackled that a bit two months ago, and I got
SetMouseEventMask() to work. What is funny though, as I said at that
time, is that SetEventMask() is in fact SetMouseEventMask(), the last
one not being implemented actually. :-) I misunderstood what those
methods should do until I did some testing on R5. :-)
As Stephan asked if someone wants to to something about this issue, I
can continue doing it and make the event mask stuff work. Unfortunately
I can't do it in this weekend because I'm out of town. If you can wait
until Monday...
bye,
Adi.
Other related posts:
