[interfacekit] Re: [Haiku-commits] r21191 - haiku/trunk/src/kits/interface
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: Interface Kit <interfacekit@xxxxxxxxxxxxx>
- Date: Sat, 26 May 2007 19:26:22 +0200
On 2007-05-25 at 17:12:01 [+0200], Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
wrote:
> On 2007-05-23 at 10:31:44 [+0200], Stephan Assmus <superstippi@xxxxxx>
> wrote:
> > Ingo Weinhold wrote (2007-05-23, 08:00:03 [+0200]):
> > > You're right. The problem occurs for classes derived from BButton. Their
> > > vtable slot still refers to BView::SetFont(), even if we override
> > > SetFont()
> > > in BButton. This issue is probably marginal, but come to think of it,
> > > invalidating the layout in a derived SetFont() is actually not a clean
> > > solution either, unless we check whether it has been invoked from within
> > > Draw(). Which is just the same that would be needed when keeping it in
> > > BView::SetFont().
> >
> > I like the idea of checking wether it is the root state. For normal
> > asynchronous windows, there is also a flag in the BWindow parent, that
> > tells
> > the view if it is "currently in transaction" (meaning inside a normal
> > redraw). It wouldn't handle the case if you call Draw() somewhere in your
> > code (which you should not do anyways), since this flag is only set by the
> > window when it receives a repaint request from the server. I guess if you
> > modify SetFont() so that it only invalidates when the font of the root
> > state
> > is set, then it would work regardless of this flag... but I don't know how
> > hard it is to know from within BView wether the state is the root state.
> > On
> > the other hand, the problem of calling Draw() yourself persists, since
> > then
> > there is no PushState() PopState() around the Draw() (unless you do that
> > yourself, which you should anyways if you call Draw() yourself).
>
> Thanks. I guess I'll simply introduce a flag in the client-side ViewState
> and
> extend the protocol to query it.
Now that I've done that (locally), I've realized, that this actually only
makes sense, if Invalidate() was called as well. If a view's size constraints
depend on the font, it obviously also needs to be redrawn when the font
changes. Considering that the current implementations of BView and derived
classes don't ever seem to call Invalidate() when generic graphics-relevant
properties (font, colors, scale, ...) are changed, I tend to revert my
changes and keep the responsibility of calling InvalidateLayout() and
Invalidate() on the side of the app developer. I personally think that sucks,
but at least it sucks consistently.
CU, Ingo
PS: Can anyone guess which kit is my primary candidate for a complete rewrite
after R1?
Other related posts:
