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

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.

Default graphics parameters are typically set as part of initializing the BView once it's attached to a windowâin an AttachedToWindow() function. 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. 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.

If Draw() is called outside of an update, it can't assume that the clipping region will have been erased to the view color, nor can it assume that default graphics parameters will be restored when it's finished.
----------------------------------------------------------------------

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.


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.

--
Marc Flerackers (mflerackers@xxxxxxxxxx)
Software Engineer

Other related posts: