[haiku-commits] Re: BRANCH looncraz-github.setviewuicolor [5636ce989d00] src/kits/interface

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 26 Oct 2015 14:34:38 +0100

Am 26.10.2015 um 13:51 schrieb looncraz:

On 10/26/2015 05:43, Axel Dörfler wrote:
Am 26/10/2015 um 02:47 schrieb looncraz-github.setviewuicolor:
5636ce989d00: Set top view color
This is, it seems, the best place to do this. It is also
necessary to
keep the _ColorsUpdated() setting for the top view.
[...]
void
BWindow::SetLayout(BLayout* layout)
{
+ fTopView->SetViewUIColor(B_PANEL_BACKGROUND_COLOR);
+ fTopView->SetLowUIColor(B_PANEL_BACKGROUND_COLOR);
+ fTopView->SetHighUIColor(B_PANEL_TEXT_COLOR);
fTopView->SetLayout(layout);

Why should a call to SetLayout() change the colors of the top view?
How would I explain this to my children? :-)

Bye,
Axel.



It really shouldn't, but it is the only way I found, after hours of
testing, that would get the Tracker OpenWith window to start with the
proper color for the top view.

Considering using a layout dictates that the top view will use system
colors (even before my patch), it really isn't a problem, IMHO.

It feels something like an app_server messaging/synchronization problem,
because the ui color is set, but not acted upon otherwise, but there is
exactly one example of when it happens - with Tracker's OpenWith window,
all other windows with layouts, everywhere, behave exactly as expected
in this regard. I noticed that Devices suddenly stopped responding
properly, I'm not sure if it's related to this or not, but I didn't
notice it until after I did this, so I'll have to dig around.

The only other app that shows any unexpected behavior is WonderBrush,
one of its views has its state crushed (either partly or in whole, not
sure) after PushState() in Draw(). How that happens, I have no idea. I
already gave as much detail as I could to Stephan Aßmus and he said
he'll get back to me once he looks at it.

The bug is mine somewhere, obviously. I keep referring back to the
original code, because mine should appear very little different, and
each little thing I do like this annoys me (thankfully, there are only
two places, and they both relate to the same issue - top view color).

I'll be digging deep, no worries.

I can't be 100% sure what Axel would be suggesting as an alternative, but he is completely right that you do something in a method that you should not be doing there. This method has a purpose and is named accordingly. Writing code like this is just bad, sorry. What you probably need to do instead is to write a separate method, call it _InitTopViewColors() or similar, and call it at the place where you need to call it, but probably not from within SetLayout(). Instead, call it where the BWindow itself calls SetLayout(), for example. I am pretty sure that in the case where BWindow::SetLayout() is called again at a later time, you should not have to set the top view colors again, too.

Best regards,
-Stephan



Other related posts: