[Interface Kit] white progressbar background in FilWip

[diver]

hrev50500

FilWip now has white progressbar background, looks like another regression.

[waddlesplash]

moving to B1 along with the other color regressions

[Janus]

The progressbar color is hardcoded.

MainWindow.cpp:174

statusBar->SetBarColor (StatusBarColor);

Costants.h.83

StatusBarColor =		{245, 187,  46, 255},

[pulkomandy]

245, 187, 46 should be orange, not white?

[looncraz]

Replying to Janus:

The progressbar color is hardcoded.

MainWindow.cpp:174

statusBar->SetBarColor (StatusBarColor);

Costants.h.83

StatusBarColor =		{245, 187,  46, 255},

Aside from being the wrong color for a status bar, this bug is about the background surrounding the control - not the bar color, which works just fine across the system.

If you have hard coded the status bar color - revert that, it's not correct. The status bar has its own, user-customizable, color setting in Appearance. This setting can be overridden by applications using SetBarColor().

I am setting this bug back to open.

[pulkomandy]

The hard-coded color is in the FilWip application, which is fine. Maybe a screenshot of the issue would help here :)

[looncraz]

Replying to pulkomandy:

The hard-coded color is in the FilWip application, which is fine. Maybe a screenshot of the issue would help here :)

A screenshot is a bit difficult, but hard-coding the color even in FilWip is a non-solution. This is a system bug in the interface kit related to inheriting background colors from parent views in a few edge cases.

[pulkomandy]

Yes, as far as I can see, the bug is not fixed, and the color which is hardcoded is the bar color, which does not fix anything and is unrelated to the issue.

[Janus]

I did not hard coded anything, I just reported that the color is hardcoded. The application has many problems.

[Janus]

Probably I used a layout version of the application, in this case there is no background problem. This explain why I did not see the bug.

[Janus]

looncraz I had some problem with BStringView in the method AttachedToWindow there is this check

if (ViewColor() == B_TRANSPARENT_COLOR)
   AdoptSystemColors();

I don't understand, the view color can be transparent in a replicant... Do I miss something?

Thanks.

[looncraz]

Replying to Janus:

looncraz I had some problem with BStringView in the method AttachedToWindow there is this check

if (ViewColor() == B_TRANSPARENT_COLOR)
   AdoptSystemColors();

I don't understand, the view color can be transparent in a replicant... Do I miss something?

Thanks.

Transparent view color is never kept. The original code:

if (color == B_TRANSPARENT_COLOR)
    color = ui_color(B_PANEL_BACKGROUND_COLOR);

With the live color system we have color constants and tint values which need to propagate from the parent for low, high, and view colors. If the view color is B_TRANSPARENT_COLOR it means we have inherited that color from the parent before it has had a chance to set its colors - several legacy applications did this. The solution is to then AdoptSystemColors() so that the string view has the default appearance.

I will have an overabundance of free time starting in just a week, I will be working nearly full time on Haiku at that point for about two weeks, so I will be addressing this bug and all others I own in earnest while I take the time to address updating all of these popular, but dated, programs' interfaces.

EDIT:

Also, I think your colors are corrupt, hit 'Default' in Appearances for colors... or delete the color settings in ~/config... or just set a proper value for the control highlight color (IIRC), it should currently be showing black... which is wrong ;-)

[pulkomandy]

​https://github.com/HaikuArchives/FilWip/commit/767ce36abb0926e12e45ba8f5c41028d2c86193a

It was a bug in FilWip.

We could make BProgressBar fill the background using the view color rather than the low color, still.