Control Look lost in child view

[Pete]

When you add a BButton to a view that is a child of a window, rather than the window itself, it shows with no "sculpturing" at all -- just a bare one-pixel-wide frame and a white background.

I'm attaching a small demo source that shows the problem. The first button (a direct child of the window) looks normal, while the second (added to a view that itself was added to the window) is 'flat'.

If you set be_control_look to NULL, both buttons are as one would expect.

[Pete]

Short source demo that shows Control Look problem

[ttcoder]

That's odd -- I have deeply nested BView hierarchies in my apps and my BButtons show up with a normal gray background... Yet if I compile ButtonLook.cpp and execute it the 'nested' BButton has a white background indeed, weird... Will look into this if I have more time.

[Pete]

Replying to ttcoder:

That's odd -- I have deeply nested BView hierarchies in my apps and my BButtons show up with a normal gray background...

I wonder if your apps might have been compiled a while ago? I suspect that ControlLook was only made the default recently. Maybe anything compiled before that will use the old-style code? I can't find anything earlier of mine that happens to use buttons in a nested view (the need came up just the other day). I have one module that has buttons in a view, but they're custom buttons, and they work fine!

It's probably only buttons. Haven't noticed it on any other controls, such as popup menus.

[axeld]

Replying to Pete:

I wonder if your apps might have been compiled a while ago? I suspect that ControlLook was only made the default recently.

Recently like 4 years ago or so. Besides, it wouldn't make any difference, since it's in libbe.so and therefore affects all applications. Since all applications just work fine, there must be something wrong with your test, or there is some subtle bug that is only triggered in your test app for whatever reason.

[Pete]

Replying to axeld:

Replying to Pete:

I wonder if your apps might have been compiled a while ago? I suspect that ControlLook was only made the default recently.

Recently like 4 years ago or so. Besides, it wouldn't make any difference, since it's in libbe.so and therefore affects all applications.

Yeah -- I realized that soon after I posted. (And I tried compiling on BeOS and running the executable in Haiku, with the same result.)

Since all applications just work fine, there must be something wrong with your test, or there is some subtle bug that is only triggered in your test app for whatever reason.

Can you point me to an app that has a button in a nested view? I was trying to find one that even used buttons, and had a lot of difficulty! And I wrote the test because the code I'm working on does require buttons in a child view, and hit the same problem whatever I did.

I would appreciate it if you would actually look at the test (:-)) (it's short) and see if I'm actually doing anything wrong.

[axeld]

Replying to Pete:

Can you point me to an app that has a button in a nested view?

Off the top of my hat: FileTypes, MediaPlayer, Screen, ArtPaint, ...

I would appreciate it if you would actually look at the test (:-)) (it's short) and see if I'm actually doing anything wrong.

I had a look, but besides the ugly coding style, I didn't see anything suspicious :-)

[axeld]

The description wasn't really correct. The button is drawn just fine, only that it has no visible background. This is because BControl actually inherits the background color from its parent.

The difference between the BControlLook version, and the old one is that the new one is taking the background color into account, and uses it as a base to draw its gradient -- which turns out not to be visible when the background is white. IOW BButton is matching its background.

Since any good UI should just use the defaults (ie. B_PANEL_BACKGROUND_COLOR) as background, it usually doesn't make a difference. I'm CC'ing stippi, maybe he has a good reason why BButton behaves this way. While I like that BButton is able to behave that way, I'm not sure this should be the default.

[Pete]

Replying to axeld:

The description wasn't really correct. The button is drawn just fine, only that it has no visible background. This is because BControl actually inherits the background color from its parent.

Unfortunately this isn't quite correct either. A button in a child view (of the window's own inaccessible view) uses the background colour of that child view, but a button added to the window itself uses B_PANEL_BACKGROUND_COLOR. (Without be_control_look they all use B_PANEL_BACKGROUND_COLOR.)

It may have sounded like a neat addition to derive from the view, but I think it doesn't work in a lot of situations. In BeOS, my app looks good (to me anyway(:-)) with grey buttons in white panels.

Since any good UI should just use the defaults (ie. B_PANEL_BACKGROUND_COLOR) as background, it usually doesn't make a difference.

Should it? I think an app should have the freedom to set its own appropriate colour scheme. I just discovered the capabilities of the Appearance preference, and also see that a 'set_ui_color()' has been added, but these settings are all global. In fact I'm very happy with the defaults for the general look, but an app may well have special needs: a red 'Panic' button, say. And I'd say it's very common to want buttons to stand out a bit from the background. There should be some application-specific, even individual control specific, way of setting such things.

[axeld]

Replying to Pete:

Replying to axeld:

The description wasn't really correct. The button is drawn just fine, only that it has no visible background. This is because BControl actually inherits the background color from its parent.

Unfortunately this isn't quite correct either.

Depends on your reading - a top level child has no Parent() to inherit from, therefore it gets the default panel background color.

Since any good UI should just use the defaults (ie. B_PANEL_BACKGROUND_COLOR) as background, it usually doesn't make a difference.

Should it?

Yes, it should. Applications are supposed to provide a decent system consistent look overall, and don't violate that for the sake of it.

I think an app should have the freedom to set its own appropriate colour scheme.

Of course there are special requirements like a red button if it has to be, but having a completely different color scheme is just annoying the user. Probably the most important aspect of UI design is consistency, and coloring is an important part of that, too.

Furthermore, it completely removes the ability to customize the colors, if you chose different ones; what looks good to you might look horrible to someone else, especially if your tint of red doesn't match the one he chooses for its applications. Personally, I would choose a standard looking application over a custom one any time, and it sure makes a bad first impression.

Having said all that, it's of course your decision in the end. It's just one opportunity of many for a design sin, if you have to take it :-)

[stippi]

First of all: Yes, I am fully aware that the BControl behavior in Haiku deviates from the BeOS behavior. I have made this decision consciously, and one of the simple reasons is that it wasn't consistent in BeOS anyway. Some controls would inherit the background color of their parent, some would not. In Haiku, I am not 100% sure that all controls have this implemented consistently, but the intention is that all controls inherit the background color of their parents. Why is this so? Because usually that is what you want, and the API should cater for the common case so that app developers usually have to write less code.

For the odd situation in which you want a BButton or any other control to have another background, simply set it via SetLowColor(). That is really all you have to do. The background is, for obvious reasons, inherited from the parent in AttachedToWindow(). This was also the case on BeOS for the controls that behaved that way. If you want to set a background at construction time, you simply override AttachedToWindow(), call the super class version first, then set your own background color. Just what you had to do on BeOS.

As for the fact that a BButton, when drawn with BControlLook against a white background does not show the edged frame... such is life. I would recommend marking the bug as invalid.

[stippi]

I have forgot to mention, for some controls I have gone pretty far to make them look properly embedded into their parent. I think BButton can optionally draw the edged frame using alpha blending against the parent, you'd have to look at the code for how this is triggered.

[axeld]

It definitely renders the frame correctly, just the background is missing (as white cannot be made any brighter for the gradient).

In any case, I agree on marking this as invalid, just wanted to have your thoughts recorded here first :-)

[Pete]

Replying to stippi:

For the odd situation in which you want a BButton or any other control to have another background, simply set it via SetLowColor(). That is really all you have to do.

Of course this is one of the things I tried early on -- with no apparent effect... But what I hadn't realized is that it has to be done after the button is attached to the view!

So, yes, everything makes sense in the end, and can work as I intend, but there are non-obvious stumbling blocks that would be helped with some documentation!