Hello Marco,
Thanks for the patch.
1/ On the implementation side: I have tried so far to keep all the magic numbers for breeze (and oxygen) in Breeze::Metrics, because it makes maintainability much easier. I think it should stays so, and not become split between Metrics and Helper. In the current implementation I see two ways to do this:

• the easy way: move the enums back to Breeze::Metrics, using e.g.

ScrollBar_Extend_Tiny, ScrollBar_SliderWidth_Tiny, ScrollBar_MinSliderHeight_Tiny (and the same widht _Default and with _Large) and let Helper (as it is now), switch between one set and the other (with no more magic nubers

• the not so easy way: make metrics a real class and move all the new Helper code there.

Either way is fine with me, for the moment.

2/ on the actual feature side:

• Large: I really don't think we need this. It looks oversized with respect to the other breeze elements, and nobody (as far as I know) never asked for larger scrollbars. I think "small" and "medium" should be enough. And I would rename them to "default" and large. (if indeed small is the default)

• small: I think scrollBar_MinSliderHeight should be increased to 10 (or 12). Hitting the handle when the scrollbar has its minimum size at 6, becomes very difficult (try open a large file in e.g. kate or kwrite). This makes the handle non-circular, but I think this is acceptable.

Still on small: I think there is something not elegant with the size of the groove and the size of the arrows on both sides of the scrollbar, when visible. arrows appear too large.
Should we make them smaller ?
Disable them by default ?
making them smaller has the inconvenient that it will become inconsistent with the other arrows in the rest of the style.

On the other hand, using 8 instead of 6 for the groove width, make the two more balanced. (but then it makes again the scrollbar larger than the progressbars).

Finally: on the need for an option (and this is true with the other commit).
Do we really need one ? Will we add an option every time we change something in the style's appearance from now on ?
I can see how this will turn breeze into qtcurve in the future, and make it unmaintainable.

Also I thought the original idea was to make breeze consistent by design, so that you do not need options. In fact, options would be a nuisance: they would either break consistency, or make it appear as if we - or rather the designers- are not sure about their designs.

I think Nuno's back in the oxygen days, also agreed with that.

In other words, I do not think having an option for whether scrollbar grove is shown on mouse-over or not, and another one on the width of the scrollbar, enters the category of "powerful when needed", so as to justify an option (well two options).

I would _really_ like to have the oppinion of VDG on that, but IMO, if we are sure about ourselves on this new scrollbar design we should just make these two defaults the only available options and stick to it.

Sorry for the long posting

I'd like to have the options if possible. I don't think we will lose consistency. Other parts of Breeze provide options like buttons in title bar size, order etc.

Hello again Marco,
Over the week-end I have used (and experienced with) the proposed slim scrollbar, and I must say I has grown on me quite some.
However I'd like to propose a slightly different metrics for the reduce scrollbar, which you could possibly test on your side too (both for the design, and the functionality):

ScrollBar_Extend = 20,
ScrollBar_SliderWidth = 6,
ScrollBar_MinSliderHeight = 18,

As you see, the slider width is at 6, as originally planed by you (and confirmed on Telegram).
The Extend however is kept at 20 (though it could be equally reduce to 18). The rationale behind it is that this way you keep the same size for the hit area as with the large scrollbar, so that there is no loss of functionality, even if the scrollbar looks more slim.
Also, 20 is used as a size for hit areas for many other elements in breeze (as you can see in breeze.h), e.g. checkboxes and radiobuttons, menu arrows, slider handles. So that it all feel "consistent".

The MinsliderHeight I have increased to 18 (and I think it could be increased even larger),

• to match better what is used e.g. in Telegram
• because it looks nice
• is confortable, hit-area wise.

Would you give it a shot ? Tell me what you think ?

As for the options, I think that with this slim scrollbar, the default should be to have no arrows on either side (this is the trend elsewhere anyway, as also mentioned on Telegram)

Finally, I still think there should be no options for this (nor for the disappearing groove), especially if we keep the scrollbar_extend at 20, because

• this new design looks gorgeous enough so that we should be proud of it and not have "after-thoughts"
• there is no loss of functionality (the hit area is the same)

(I would tend to limit options to added/removed functionalities, rather than just design choicies).

But in the end it is up to you and the VDG to decide.
I can discuss this further (and lay my arguments) on Telegram if need be, since I am now logged in there also.

One screenshot, with the metrics suggested above: http://wstaw.org/m/2016/11/02/plasma-desktopna2488.png

It does make sense to me to give the option to turn the slim scroll bar as such on and off. I can imagine some people being uncomfortable with the animation on mouseover.
Being able to configure individual parameters is probably overkill, however.

In D3210#60184, @colomar wrote:

It does make sense to me to give the option to turn the slim scroll bar as such on and off. I can imagine some people being uncomfortable with the animation on mouseover.
Being able to configure individual parameters is probably overkill, however.

So, just to make sure I understand:

• 1 option to "only show full scrollbar on mouse over" (as we have now)
• 1 option to "use slim scrollbar" (with reduced width handle)

Is that what you have in mind ? or do you suggest to group the two ?
(in which case I'm pretty sure some users will want one and not the other, namely slim scrollbar with groove always visible, no groove but large handle, etc.)

Also,

• what about keeping the hit area unchanged (20 pixels), and consistent with the rest of breeze, this whether the scrollbar is slim or not ?
• and what about an even larger toolbar (as in the current patch) ? (which I think is not necessary, and inconsistent with the rest of breeze).

Note that if we don't add a larger scrollbar, then the current combobox can be turned into a simple checkbox (which I would find preferable too).

Thanks for the feedback,

Hugo

One last comment about options: every time one adds one, one make the code maintenance more complicated, with more combinations to test each time a change to the code is made. Just saying :)

In D3210#60230, @hpereiradacosta wrote:

So, just to make sure I understand:

• 1 option to "only show full scrollbar on mouse over" (as we have now)
• 1 option to "use slim scrollbar" (with reduced width handle) Is that what you have in mind ? or do you suggest to group the two ? (in which case I'm pretty sure some users will want one and not the other, namely slim scrollbar with groove always visible, no groove but large handle, etc.)

personally, (and would be good if thomas, jens or alex from the cdg weigh on that) I would have the default as:

• small scrollbar
• show on mouseover enabled
• no arrow buttons

tough i feel there may be the need for configuration options, even tough i usually really dislike them, for the code complexity reason you rightly mentioned

Thanks for the feedback,

Hugo

One last comment about options: every time one adds one, one make the code maintenance more complicated, with more combinations to test each time a change to the code is made. Just saying :)

yep, i fully agree with that.
unfortunately over the years i seen the storm that can happen every time one changes anything visual (seems that changing the size of something is even more delicate as shown by a recent storm over systray icons size) so yeah, I'm just a bit afraid to :) (could fall into the category of the "omg they are pushing a mobile ui on me" kind of hater)

we could even try to make this not configurable for 5.9 and see what the feedback is and eventually get the options back later..

personally, (and would be good if thomas, jens or alex from the cdg weigh on that) I would have the default as:

• small scrollbar
• show on mouseover enabled
• no arrow buttons

+1 on this.
Been using this setup for few days now and am very happy with it

tough i feel there may be the need for configuration options,

ok :)
so far I have been the only one advocating for not having an option anyway.

even tough i usually really dislike them, for the code complexity reason you rightly mentioned

<snip>

we could even try to make this not configurable for 5.9 and see what the feedback is and eventually get the options back later..

yes. In fact you could even push the code "as is", but removing without the ui elements. (to have "hidden" options)

If I understood it correctly (that there is only a checkbox "Only show full scrollbar on mouse over" added to the config) then that is exactly what I had in mind.

In D3210#60493, @colomar wrote:

If I understood it correctly (that there is only a checkbox "Only show full scrollbar on mouse over" added to the config) then that is exactly what I had in mind.

in this latest version there are 2 checkboxes: "show scrollbar only on mouse over" and "small scrollbar" which both defautls to true

In D3210#60602, @mart wrote:

in this latest version there are 2 checkboxes: "show scrollbar only on mouse over" and "small scrollbar" which both defautls to true

Why do we need both? What happens if one checks the first but not the second? What happens if one checks the second, but not the first?
I fear we might be making things more complicated for users than necessary. I see only two useful scenarios:

1. Small scrollbar that expands on mouseover
2. Always big scrollbar

In D3210#60962, @colomar wrote:

In D3210#60602, @mart wrote:

in this latest version there are 2 checkboxes: "show scrollbar only on mouse over" and "small scrollbar" which both defautls to true

Hi Colomar,

Why do we need both? What happens if one checks the first but not the second?

You get a large scrollbar, visible only on mouse-over

What happens if one checks the second, but not the first?

you get a small scrollbar that is always visible

I fear we might be making things more complicated for users than necessary. I see only two useful scenarios:

1. Small scrollbar that expands on mouseover
2. Always big scrollbar

If we make it so, I am sure there will be some (how many ?) users who will ask for the two combinations that I describe above, and which are not covered by your choices 1 or 2.
And IMHO their requests would be as valid as the one covered by 1. or 2.

Which is why I think "no" option would actually be better.
In other word, either you have 2 checkboxes that cover all four possible combinations, or you start to make arbitrary (design based) choices to reduce this number of combinations. Now if you go along that path, you might as well leave only one combination. (the one that is the most consistent with the design you want for breeze, and that does not reduce functionalities with respect to the old design).

In D3210#60963, @hpereiradacosta wrote:

Which is why I think "no" option would actually be better.
In other word, either you have 2 checkboxes that cover all four possible combinations, or you start to make arbitrary (design based) choices to reduce this number of combinations. Now if you go along that path, you might as well leave only one combination. (the one that is the most consistent with the design you want for breeze, and that does not reduce functionalities with respect to the old design).

I don't have much opinion on this (with just a slight preference for the 2 options way), so once decision is achieved, either no, 1 or 2 opinions, I'll adapt the patch

In D3210#60963, @hpereiradacosta wrote:

Why do we need both? What happens if one checks the first but not the second?

You get a large scrollbar, visible only on mouse-over

So that means it would be completely hidden as long as the mouse is not over it? I don't think that was ever the plan, but instead to have an always-visible small scrollbar which expands on mouseover.

What happens if one checks the second, but not the first?

you get a small scrollbar that is always visible

That would have bad usability due to the small hit area, though, wouldn't it?

I fear we might be making things more complicated for users than necessary. I see only two useful scenarios:

1. Small scrollbar that expands on mouseover
2. Always big scrollbar

If we make it so, I am sure there will be some (how many ?) users who will ask for the two combinations that I describe above, and which are not covered by your choices 1 or 2.
And IMHO their requests would be as valid as the one covered by 1. or 2.

The other two scenarios would each have usability problems (as described above), though. Do we really want users to be able to create their own usability problems by making problematic choices?

Which is why I think "no" option would actually be better.
In other word, either you have 2 checkboxes that cover all four possible combinations, or you start to make arbitrary (design based) choices to reduce this number of combinations. Now if you go along that path, you might as well leave only one combination. (the one that is the most consistent with the design you want for breeze, and that does not reduce functionalities with respect to the old design).

It isn't just "design-based" as in "aesthetics-based": The two options I described are the ones with the least usability problems. The only reason why I tend towards providing an option to switch off the mouseover-effect is that some people have problems with animation and therefore want to reduce them as much as possible,

Hi Colomar,

no usability problem no. (at worst some miswording, and misunderstanding)

In D3210#61496, @colomar wrote:

In D3210#60963, @hpereiradacosta wrote:

Why do we need both? What happens if one checks the first but not the second?

You get a large scrollbar, visible only on mouse-over

So that means it would be completely hidden as long as the mouse is not over it? I don't think that was ever the plan, but instead to have an always-visible small scrollbar which expands on mouseover.

Ok. No. What I meant is (reusing your terms): an always-visible *large* scrollbar which expands on mouseover.

What happens if one checks the second, but not the first?

you get a small scrollbar that is always visible

That would have bad usability due to the small hit area, though, wouldn't it?

Here I meant, an always visible small scrollbar without extend on mouse over (because always expanded).
There really is no usability difference between these two cases and the other two.
But the easiest is probably to just give it a try
(It feels we are on a "train rack" right now)

I fear we might be making things more complicated for users than necessary. I see only two useful scenarios:

1. Small scrollbar that expands on mouseover
2. Always big scrollbar

If we make it so, I am sure there will be some (how many ?) users who will ask for the two combinations that I describe above, and which are not covered by your choices 1 or 2.
And IMHO their requests would be as valid as the one covered by 1. or 2.

The other two scenarios would each have usability problems (as described above), though. Do we really want users to be able to create their own usability problems by making problematic choices?

Which is why I think "no" option would actually be better.
In other word, either you have 2 checkboxes that cover all four possible combinations, or you start to make arbitrary (design based) choices to reduce this number of combinations. Now if you go along that path, you might as well leave only one combination. (the one that is the most consistent with the design you want for breeze, and that does not reduce functionalities with respect to the old design).

It isn't just "design-based" as in "aesthetics-based": The two options I described are the ones with the least usability problems.

Nope. See above

The only reason why I tend towards providing an option to switch off the mouseover-effect is that some people have problems with animation and therefore want to reduce them as much as possible,

oh, but then we already have an option to turn off animations (all of them).
You are right that we could (should ?), disable this one along with the others, and make the scrollbar groove always visible, when animations are disabled.
marco ? Wdyt ?

Whoa okay, that is complex...
Given that I failed to understand what the proposed checkboxes were supposed to mean, I fear it will be the same for users.
Therefore maybe not gibing the option at all is indeed the better solution, and your suggestion to turn the feature off when animations are turned off makes sense to me as well.

In D3210#61533, @colomar wrote:

Whoa okay, that is complex...
Given that I failed to understand what the proposed checkboxes were supposed to mean, I fear it will be the same for users.
Therefore maybe not gibing the option at all is indeed the better solution, and your suggestion to turn the feature off when animations are turned off makes sense to me as well.

sorry for the late reply
ok, so if i understood correctly:
I'll remove those 2 options, and have instead both showing the scrollbar on hover *and* the scrollbar size depend uniquely for the global enabled state of animations?

In D3210#62062, @mart wrote:

sorry for the late reply
ok, so if i understood correctly:
I'll remove those 2 options, and have instead both showing the scrollbar on hover *and* the scrollbar size depend uniquely for the global enabled state of animations?

Yes, that is the idea.

• When animations are off, always show the scrollbar with the same size it currently has
• When animations are on, show the slim scrollbar by default and make it big on mouseover

Would that work?

done. It looks maybe a bit too "magic", but may be a good thing

I fear there is still some misunderstanding here. Maybe it is due to the original animation send for the other modification.
Maybe to make it clear to colomar:
for a vertical scrollbar, the current animation does _not_ change the width of the scrollbar. The only thing it does is to make the scrollbar "groove" below it (the grey area that indicates the range along which the handle can move) appear gradually.
The other dimension is unchanged. (and the hit area is unchanged too)
Consequently, changes on the groove visibility and on the scrollbar width, to me at least, are completely uncorrelated.
I think this is why Marco wanted two options from the beginning, and I was arguing with either two or no option (but certainly not "one" option)

Now the current situation, for which both the animation (the appearance of the groove) and the width of the scrollbar are controlled by the "enable animation" option, indeed sounds quite like magic to me (why would animations control the width of an object ?). I don't think this is satisfactory. Options must do what they are supposed to.

So (and sorry for all the back and forth). I would make the "enable animation" option control *only* whether the groove fades-in and out on mouse-over, or is permanently drawn.
For the scrollbar width: either we have a separate option for that ("use thin scrollbars"), or we make the thin scrollbar the one and only scrollbar design. (And I would advocate for the second solution, keeping the full scrollbar width - including the empty sides- unchanged, as well as the corresponding hit area).

this version always has a small scrollbar, show on hover enabled when animations are enabled

In D3210#62696, @mart wrote:

this version always has a small scrollbar, show on hover enabled when animations are enabled

+1 for me.

Personally, I would leave the _scrollBar_Extend to 20, to have the same hit area as before, and increase the MinSliderHeight to 20 too, but at this stage, we need to push "something" and possibly adjust later.

Also, assuming that Colomar is also ok with this change, if we stick to only one scrollbar size, then it can move back to Metrics (and not in Helper).

I haven't had the chance to play with it and I think we should still have a plan B if we get negative feedback on it during beta tests, but the concept as it is described in the latest comments makes sense to me.

We ends with no configurable scrollbar size at all, it has plan for this *really* ?

In D3210#83622, @anthonyfieroni wrote:

We ends with no configurable scrollbar size at all, it has plan for this *really* ?

Indeed. This was deemed unnecessary (see discussion above), with respect to the added code complexity.

This [configurable scrollbar size] was deemed unnecessary

In a discussion with a very select audience, which neither seem to suffer from a HiDPI setup or limited visual ability.
Few people among those who experience discomfort with a current implementation try to make their voice heard.

https://bugs.kde.org/show_bug.cgi?id=396747 (misleadingly marked fixed, but its definition of thick is the current slim implementation)
https://bugs.kde.org/show_bug.cgi?id=416003 (read for usage scenarios)
https://askubuntu.com/questions/925408/how-to-change-kde-plasma-scrollbar-width (half-working hacks people resort to)

Why again did scrollbars and touch items become tiny on all platforms when display density is increasing? Lacking the option to choose a more comfortable size is really frustrating for many users. Mabe if the animation that was introduced in breeze would at least scale up the thumb slider..