[haiku-appserver] Re: [Haiku-commits] r13174 - haiku/trunk/src/kits/interface

Hi Marc,

Marc Flerackers wrote:
Um... R5 behaves different than we thought.
For example, if I do a PushState() and change the high color every time when I press a mouse button, and in Draw() I fill the bounds with the high color, when moving the window outside the screen and back again, the window is cleared in the last color set by SetHighColor() in MouseDown().
This means it does not reset to initial state, but use the one active before Draw() was called.
I don't know if that's good or bad... we have to decide. 


That's completely normal and documented :)

http://www.beunited.org/bebook/The%20Interface%20Kit/1_Drawing.html

----------------------------------------------------------------------
Drawing outside of an Update

Graphics parameters that are set outside the context of an update are not limited; they remain in effect until they're explicitly changed. For example, if application code calls Draw(), perhaps in response to an interface message, the parameter values that Draw() last sets would persist even after the function returns. They would become the default values for the view and would be assumed the next time Draw() is called. 

    Yes, and how does this differ on what me and Axel have agreed on?
The above paragraph talks about graphics parameters not graphic states.

Default graphics parameters are typically set as part of initializing the BView once it's attached to a windowâin an AttachedToWindow() function. 

    Graphics parameters, ok, no problem.

If you want a Draw() function to assume the values set by AttachedToWindow(), it's important to restore those values after any drawing the BView does that's not the result of an update. 

    Yup. Logical.

For example, if a BView invokes SetHighColor() while drawing in response to an interface message, it will need to restore the default high color when done. 

    From what is said above, we're only _operating_ on the current
(initial too) state.

If Draw() is called outside of an update, it can't assume that the clipping region will have been erased to the view color, 

    Of course.

nor can it assume that default graphics parameters will be restored when it's finished. 

    Sure, because that's done in BWindow::DispatchMessage()::case _UPDATE_,
before and after calling ->Draw();

----------------------------------------------------------------------

Like stephan said, it's done so you can set the "default" state of the view yourself, in AttachedToWindow for example. Most programs use this behaviour like this. 

    And it's a good use! :-)

        Me and Axel were talking about a different thing. In fact your email
supports this. As the bebook says, before Draw() is called _it is assumed_
that the default state is active. That's what me and Axel want. In R5, this
does not happen, the last pushed state is considered "the default state".

Another thing that R5, IMO, does badly is that before calling Draw() on an update event it pushes the current state and after Draw() is finished it calls PopState(), only once!
So, if I do a lot(try 2) of push states in Draw(), when we get out of it, the state remaining active is one of those pushed in Draw(). Is that correct?
Shouldn't we go back to the state which was active before Draw() was called?
Shouldn't we reset to the initial state, push a state and then enter Draw()?

If a developer pushes twice during draw, he is expected to pop twice before ending draw, otherwise he has a bug in his code. The same can happen in other api's like opengl for example. 

    It's not about the developer. It's about a healthy system.
So what if the developer mistakes, we can help him. The framework must
lift the burden from the developer, not impose it! Smart software guys. :-)


bye,
Adi.

Other related posts: