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

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sun, 19 Jun 2005 21:47:42 +0300


Axel Dörfler wrote:
That state must always be the initial state, anyway, doesn't it?

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.

I would rather think it's bad, ie. let's not follow the path set by R5, and see how many problems that bring us :-)

Okay then, we'll revert to the initial/first state before calling draw.

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()?

Same as above, I think we should aim for the cleanest solution, and if that doesn't work out, get gradually worse until it does.

Good. The initial/first state will be the one active after Draw() finished.

Axel Dörfler wrote:

[view lookup by token]

> I couldn't help but have a look at it and shuddered. Do you intend
> fix this one day or do you think just searching for the token this
> would be okay??
> Because it's not okay, only as a temporary solution we can live
with it
> right now.
Don't know, maybe. But right now I don't plan to. It's good how it is now.

I really don't understand how you code: sometimes you live with the almost ugliest design in order to save a few cycles (or believe you do so), but in other places like these, you're throwing it all away and don't even want to notice it.

:-D. Not quite. It's not a big deal in this case.

Code like this scales extremely badly. It might be negligible if you restrict an application to 5 or so views, but that just sounds very unlikely to me. Sure, it's perfectly fine at this time of development (since it works, unlike so many other parts), but that doesn't make it okay for production code.

You're right.

bye, Adi.

Other related posts: