[haiku-appserver] Re: progress and status

Hi,

>>That being said, I think that the code is correct for the synchronous 
>>controls version. If we block the window message loop, we obviously 
>>don't have Draw() called for us, so we need to call it directly. Not 
>>using B_ASYNCHRONOUS_CONTROLS windows is long deprecated, but I know we 
>>need to support it nevertheless.
> 
> Ok, agreed.
> 
>>In our BView implementation, I think that the different drawing 
>>commands don't flush the app_server link. They simply place a message 
>>into the queue. The command doesn't get executed until something else 
>>causes the queue to be flushed. In the drawing methods, I think we 
>>should differentiate wether we are currently called from within Draw() 
>>or just like that. In the later case, we should automatically flush. I 
>>don't know how R5 handles this.
> 
> 
> I just had a small discussion with Marc Flerackers about that.

        I had long ones about 2 years ago. :-)

> He said that r5 flushes the command buffer every time a reply is needed
 > AND PERIODICALLY (probably in the looper thread).

        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)
- some commands need to stay in sync with the server and in their body 
(Bounds() for example) they flush the buffer and wait for a reply.
- Sync() is/will be called after a message (any) is dispatched in 
BWindow's thread.

> R5 can do that because
 > graphic messages aren't really messages, but instead, there is a stream
 > of commands. That's one of the reasons why BMessages weren't used for
 > this task: Bmessages need to be completed before being sent (there is no
 > support for incomplete BMessages), a stream of commands does not need to:
 > the app server can just start drawing as soon as it gets the first 
command.

        We have better. Our messages will be buffered just like in R5, but 
what's nicer is that they are complete.

> That's a big difference from what we have, because BPortLink still
 > sends/receives complete messages. I don't know if we can flush the ports
 > periodically too, and what would happen if we started doing that.

        We can. And we do that. ;-)

> Note: I suggest you to  speak with Marc as he's the guru in there,
 > this is just what I've understood :P

        You can talk with me and DW as we both know pretty well how this stuff 
works.

>>If blocking inside MouseDown(), the messages from the >app_server should 
>>still be appended to the queue, and if this does not happen, >then its a 
>>bug. Do you want to investigate this?

        That's not a bug, because it's not possible.
        BWindow thread is in task_looper()->DispatchMessage()->MouseDown() and 
it's blocked here until MouseDown() returns. What happens is, messages 
from the server (and other threads) will enqueue in kernel's port queue 
that BLooper created. (have a look at BLooper::task_looper())


        I'm afraid I do not understand the discussion you guys are having. (I 
need to remember you I haven't programmed BeOS very much) So excuse me 
for asking: What is your problem? What do you need?
        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!
        (Another approach: put all message for BWindow's port in BLooper's 
MessageQueue(), search for _UPDATE_ message, pull it out from
MessageQueue() and call DispatchMessage(updateMsg, Window()); )

        Hope this clears things a bit. If I'm totally off, then please explain 
what is it you want.


Thanks,
Adi.

Other related posts: