[haiku-appserver] Re: GetMouse()

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 30 May 2005 21:00:20 +0300

Axel Dörfler wrote:
>>>use UpdateIfNecessary() is not GetMouse() itself but the context 
>>>it's 
>>>usually used in (MouseDown()).
>>
>>      I'm not too happy with this method. I think it does not respect
>>the logic, in general. I just asked for mouse coordinates, not for a 
>>UI
>>update. The fact is that I can call GetMouse() from everywhere in 
>>window's
>>context and not actually wanting to update the UI.
> 
> GetMouse() does not ask for an UI update either, it just makes sure 
> they are processed when there is an =5FUPDATE=5F message in the queue.

        Yes that we know. What I asked, and Stephan seems to ask the same 
thing, is why(the reason) do we process update requests in a method that 
queries for mouse status?
        If no good reason emerges, maybe we should remove this functionality 
from GetMouse() in R2.

>>      IMO, in R2 this method should only return mouse location and
>>buttons. What do you think=3F Also I think we should remove support for
>>synchronous controls in R2. Opinions=3F
> 
> I'm not sure about this. We should investigate this with every 
> application that needs it, and if the same could be achieved in 
> asynchronous mode.

        Stefano and Marc told us some good reasons. :-)

        But then again, why is it that we have this method if polling is 
required and BLooper/BMessage mechanism is ignored. Maybe it would be 
best that we have a general/global function to return mouse status and 
remove BView::GetMouse() altogether.

> What I am sure of, however, is that we should switch to asynchronous 
> mode by default, and only allow synchronous mode if specifically asked 
> for.

        Second that. Also, if our studies show that we don't necessarily need 
synchronous mode in a BLooper type thread, we should drop synchronous 
support.

>>>I thought DoUpdate() does that already=3F Or was that only the plan=3F
>>
>>      No, no... DoUpdate() calls Draw() methods for every view that's
>>inside the invalidated rect.
>>      DoUpdate() must not be modified, instead we should ask 
>>synchronously
>>the server if it has an invalid region to pass to us, and force a 2nd 
>>update
>>if one supplied. (DoUpdate() still has to be cleaned up. :-) Will do 
>>that
>>someday)
> 
> That would be fine by me, too :-)

        OK, I'll add a TODO in there. :-)


bye,
Adi.

Other related posts: