[haiku-appserver] Re: progress and status

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Wed, 18 May 2005 13:03:16 +0300

Hi,

Stefano Ceccherini wrote:
>>      Yes, in the looper thread too.
>>      A flush occurs when:
>>- Flush() or Sync() is called.
>>- when the current message that is being composed does not >fill in the 
>>remaining space of the send buffer. (complete commands that >are in this 
>>buffer are sent and the one being constructed is copied at >the start of 
>>buffer - at least that's how I remember it)
> 
> Ok, but are we flushing periodically ?

        Not at a specified amount of time.
        But yes, we flush periodically - when the buffer fills up.

 > I would think we are not, as some things (like for example the blinking
 > caret in BTextView) don't work unless we flush every time.

        You say that compared to R5?
        That may be because a ::Flush() is not yet present in BWindow's
task_looper() after a message is dispatched.
=============
                        }
+                       Flush();
                        //      Unlock the looper
                        Unlock();

=============

>>      You can talk with me and DW as we both know pretty >well how this stuff 
>>works.
> 
> Sorry, didn't mean to minimize your knowledge on this subject :)

        :-) You took it the wrong way. I just wanted to point of that
me and DW know well this stuff, and if you have any questions you can just
fire them up in this list. ;-)

>>      You need to have UpdateIfNeeded() working, or what? To >implement this 
>>method we need to enqueue all messages from BWindow/BLooper's >port into 
>>BLooper's MessageQueue() and search for _UPDATE_ message. >There must be 
>>only one! Then simply do exactly what 
>>BWindow::DispatchMessage()::case_UPDATE_ does - call Draw() >where it's 
>>needed. In other words: we take the _UPDATE_ message and >process it NOW!
> 
> 
> Can you have a look at my latest commit in BView::GetMouse() ?
 > I left a todo. I'm not sure we should call DispatchMessage() in there.
 > BTW, it's still not working as it should, and since you wrote that code...
 > (did you ? :)))

        Yes, I did. :-) But back in those days I didn't know all the intricacies
of app_server+BWindow+BView.
        OK, I had a quick look. (Maybe I escaped something. if so, tell me)

        First of all, we need to make sure we are BWindow thread. Second thing,
take all message from BWindow's port and put them in the MessageQueue().
        Then search for B_MOUSE_UP and B_MOUSE_MOVED messages, and while doing
so, take the _UPDATE_ message that you may find and dispatch it. Calling
DispatchMessage(updateMsg, window) is OK - I don't see any problem by doing so.

        One thing I don't understand from the current implementation is why
*location is not updated with the coordinates found in up or moved messages?
Why is it that we just eat up those messages and take nothing from them? Also,
we should return if we find one of the two messages, not continue and ask
app_server for mouse location.

        Another thing that is wrong is that when sending 
AS_LAYER_GET_MOUSE_COORDS
message to app_server we attach a "reply port". Why?
        When waiting for a reply from the server, we call:
owner->fLink->GetNextReply(&rCode);
        which already waits on the port BWindow's constructor created.

owner->fLink->Attach<port_id>(owner->fLink->GetReplyPort());
        needs to go.


bye,
Adi.

Other related posts: