[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
Evening,
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
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.
:-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.
- References:
Other related posts:
- » [haiku-appserver] Re: [Haiku-commits] r13174 - haiku/trunk/src/kits/interface
- » [haiku-appserver] Re: [Haiku-commits] r13174 - haiku/trunk/src/kits/interface
- » [haiku-appserver] Re: [Haiku-commits] r13174 - haiku/trunk/src/kits/interface
- » [haiku-appserver] Re: [Haiku-commits] r13174 - haiku/trunk/src/kits/interface
- » [haiku-appserver] Re: [Haiku-commits] r13174 - haiku/trunk/src/kits/interface
- » [haiku-appserver] Re: [Haiku-commits] r13174 - haiku/trunk/src/kits/interface
- » [haiku-appserver] Re: [Haiku-commits] r13174 - haiku/trunk/src/kits/interface
- » [haiku-appserver] Re: [Haiku-commits] r13174 - haiku/trunk/src/kits/interface
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 intendto> fix this one day or do you think just searching for the token thisway> would be okay??
> Because it's not okay, only as a temporary solution we can livewith 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.
You're right.
bye, Adi.