[haiku-appserver] Re: [Haiku-commits] r13174 - haiku/trunk/src/kits/interface
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Sun, 19 Jun 2005 18:57:23 +0200 CEST
Hi Adi,
Adi Oanca <adioanca@xxxxxxxxxxxxx> 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 :-)
> 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.
> Axel Dörfler wrote:
[view lookup by token]
> > I couldn't help but have a look at it and shuddered. Do you intend
> > to
> > fix this one day or do you think just searching for the token this
> > way
> > 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.
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.
Bye,
Axel.
Other related posts:
