Scrollbar does not merge with window border anymore in Tracker

[axeld]

I'm using Noto Sans Display 13pt, and only the right scrollbar border merges with the window border, both the horizontal, and the vertical scrollbar end one pixel too early in vertical direction.

[axeld]

hrev54460.

[axeld]

Also, the scroll bar button arrows seem to be rendered slightly heavier which makes them stand out a touch too much.

[X512]

I mentioned this problem in last comment of #16368.

[pulkomandy]

I think the purely linear-to-font-size scaling of scrollbars is also not that great.

I use 10pt font size and the smaller scrollbars are a lot more difficult to hit.

I think having hardcoded steps (16, 24, 32px) for the scrollbar size would feel better, or at least have a minimum size of 16px even at smaller font sizes.

[axeld]

I would also prefer if the knob size would dictate the scrollbar size. It just looks ugly to separate the two, and it's quite annoying to have apps behave differently, ie. have differently sized scroll bars depending on which app you use.

There could be an option to enable adapting the decorator size to the font size as well. Then you would of course have apps that don't support this, but in general, things would look more consistent. And most apps could be fixed over time, too.

I would also argue that the default size should also be the minimal size. I don't think smaller ones could ever be that useful.

[waddlesplash]

I think to fix this properly we may need to change BScrollBar to have a "borderless" mode, or at least a way to turn off specific borders...

[X512]

Border problem is usually solved by 1 px overlapping.

[waddlesplash]

Yes, and that should be there at 12pt, but I guess above 12pt it is not working out quite right?

[X512]

Proposed fix: ​https://review.haiku-os.org/c/haiku/+/3093.

[X512]

Such problems are easy to identify with my TraverseApps2 utility. When picking count view, it is visible that count view do not include upper border.

[waddlesplash]

Merged in hrev54465. Thanks!

[nielx]

Assign fix to milestone:R1/beta3, as it looks like this fix will be part of that release.

As we started with the previous beta, we would like to use the Milestone field for fixed tickets to log from which release the improvement will be out. Therefore it is very much appreciated to assign the milestone when closing a ticket as fixed.

[nielx]

Reverting ticket update, it seems to be a fix to a regression added _after_ milestone:R1/beta2, so it would be incorrect to add this to the list of fixes in milestone:R1/beta3.

My apologies for the noise.