Wrong colour for BSlider hash marks

[humdinger]

This is hrev50010.

After looncraz' colouring merge, the hash marks are no longer a subtle grey, but stark blue.

Before:

After:

[humdinger]

before the merge

[humdinger]

after the merge

[looncraz]

This is intentional - they use the control mark color... since they are hash *marks* and all :p

BStatusBar and BCheckBox also use the control mark color while default button decorations use the control highlight color.

As for the hashmarks, I thought maybe mixing them with a tinted panel color would help subdue the effect more, because it can be quite stark at times (try it with yellow :p).

[humdinger]

Well, to be exact, only one hash mark should be marked then: the one the slider knob stands over...
There are also cases, where the value/knob position doesn't snap to a hash mark (see e.g. Touchpad prefs). In that case it's only decoration that helps roughly estimating some value, I guess.

Since it looked nice before and not so nice now, maybe the use of the control mark colour should be reviewed.

[looncraz]

Replying to humdinger:

Well, to be exact, only one hash mark should be marked then: the one the slider knob stands over...
There are also cases, where the value/knob position doesn't snap to a hash mark (see e.g. Touchpad prefs). In that case it's only decoration that helps roughly estimating some value, I guess.

Since it looked nice before and not so nice now, maybe the use of the control mark colour should be reviewed.

I'll create a couple of different patches as there are a few ideas I have that might look better than either keeping this or reverting...

[waddlesplash]

Also, BFilePanel's title view has a focus ring that it shouldn't have since the merge.

[looncraz]

Replying to waddlesplash:

Also, BFilePanel's title view has a focus ring that it shouldn't have since the merge.

You mean the navigation ring? Because I'm looking at them side-by-side without a single bit of difference in that regard. The disabled default button, though, does look different (using 172, 172, 172 leads to a slightly darker disabled border), so I'll have to address that.

​http://files.looncraz.net/svc/FilePanel-Before.png ​http://files.looncraz.net/svc/FilePanel-After.png

(I also have a few different options for how to address this difference in appearance to make it less intrusive - but they are control marks, so they should use the control mark color in some way, IMHO...). I'll be posting a few patches from which to choose today or tomorrow, depending on my schedule (probably today).

[waddlesplash]

No, I mean the extra blue border on "22 items".

[looncraz]

Replying to waddlesplash:

No, I mean the extra blue border on "22 items".

OH! I see that now :p

I'll investigate that too (no clue how that got there, I'll have to look at the diffs...).

[looncraz]

​http://files.looncraz.net/svc/slider/

I created two different patches for how the patch could be handled.

The first way I called "Slider-dualcolor"

It makes the hashmark look very thin, as well as mutes the color somewhat so that it blends more with the background.

The second way is just to mute color, but still using the full color.

I was going to work on a third option as well, which involved mixing only a small amount of the control mark color into the lighter part of the mark, but time is not my friend for a few days.

I also thought of completely restoring the original coloring and creating a position indicator, with color, to indicate the position. It would just be a three-pixel wide indicator, the center being full control mark color, and the edges being heavily blended with the panel background color (barely being a hint that they even exist left). But that, obviously, takes more time to perform. I'll probably tinker with it with whatever downtime I have.

[jessicah]

That's not what the B_CONTROL_MARK constant is used for. In pre-merge ControlLook, it was pretty much the exclusive realm of checkboxes and radio buttons, and should stay this way. The other solutions are just hacks around what is genuinely a mistake when this behaviour was changed.

[looncraz]

Replying to jessicah:

That's not what the B_CONTROL_MARK constant is used for. In pre-merge ControlLook, it was pretty much the exclusive realm of checkboxes and radio buttons, and should stay this way. The other solutions are just hacks around what is genuinely a mistake when this behaviour was changed.

If we use R5.1/dan0 as a reference, the control highlight color should be used for those purposes... but that's just because the mark color didn't exist, IIRC... though dan0 didn't use the control highlight color for the hashmarks, it used a very different way of drawing sliders (a really nice way, IMHO: ​http://files.looncraz.net/Dan0Slider.png ).

In the end, the only "right" way is the way that is agreed upon. To me, a control which has indicator marks... should probably use the control mark color in some way :p. Granted, I think it would be best used on only the selected mark... but the hashmarks don't always line up with the usable values, so it'd have to be an overlay indicator.

I do like the thin marks, though.

Restoring the former behavior is a simple matter of using B_PANEL_BACKGROUND_COLOR instead of B_CONTROL_MARK_COLOR, if everyone is so resistant to changing the previous appearance (I can always work on my own control look if I were adamant :p).

[pulkomandy]

I agree whith jessicah. The B_CONTROL_MARK is used when a control is "marked", that is a checked checkbox or radio button. The selected mark in a slider may be marked in such a way too, but certainly not all the marks on the slider.

[jackburton]

Replying to looncraz:

Replying to jessicah:

That's not what the B_CONTROL_MARK constant is used for. In pre-merge ControlLook, it was pretty much the exclusive realm of checkboxes and radio buttons, and should stay this way. The other solutions are just hacks around what is genuinely a mistake when this behaviour was changed.

If we use R5.1/dan0 as a reference, the control highlight color should be used for those purposes... but that's just because the mark color didn't exist, IIRC... though dan0 didn't use the control highlight color for the hashmarks, it used a very different way of drawing sliders (a really nice way, IMHO: ​http://files.looncraz.net/Dan0Slider.png ).

I agree this looks nicer. We had this look in BChannelSlider, although it was removed because it didn't look consistent with the normal BSlider. Moreover, ChannelSlider uses a different api to draw the thumbs and the rest. It's still in the git history, though, but should be extended to BSlider, if we want to adopt it.

[looncraz]

Return to original appearance.

[pulkomandy]

Applied in hrev50039.