Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#7921 closed bug (invalid)

Control Look lost in child view

Reported by: Pete Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/alpha3
Keywords: Cc: stippi
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (1)

ButtonLook.cpp (1.8 KB) - added by Pete 8 years ago.
Short source demo that shows Control Look problem

Download all attachments as: .zip

Change History (13)

Changed 8 years ago by Pete

Attachment: ButtonLook.cpp added

Short source demo that shows Control Look problem

comment:1 Changed 8 years ago by 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.

comment:2 in reply to:  1 ; Changed 8 years ago by 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.

comment:3 in reply to:  2 ; Changed 8 years ago by 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.

comment:4 in reply to:  3 ; Changed 8 years ago by 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.

comment:5 in reply to:  4 Changed 8 years ago by 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 :-)

comment:6 Changed 8 years ago by axeld

Cc: stippi added

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.

comment:7 in reply to:  6 ; Changed 8 years ago by 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.

comment:8 in reply to:  7 Changed 8 years ago by 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 :-)

comment:9 Changed 8 years ago by 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.

comment:10 Changed 8 years ago by 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.

comment:11 Changed 8 years ago by axeld

Resolution: invalid
Status: newclosed

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 :-)

comment:12 in reply to:  9 Changed 8 years ago by 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!

Note: See TracTickets for help on using tickets.