I like the overall direction of this addition. I would add some graphical design changes to help the overall design.

1. When the scrollbar is not hovered the scrollbar width is slim. However, when the mouse hovers the scrollbar, the scrollbar's width thickens. I would suggest keeping the same width for the scrollbar throughout the entire interaction.

2. Colors are very important here. Highlighting the scrollbar track using dark grey is a bit too much. I would suggest keeping white #FFFFF for the track where the scrollbar is and only showing/hiding the top and bottom arrows making it look as if only those are appearing and the scrollbar. Nothing else.

Hello,
the idea is nice. For the implementation however, rather than changing the opacity of the painter, I think it would be more efficiency with changing the opacity of the colors that are passed to the various rendering methods instead.
As for the other design changes suggested in the comments:

• this should go to different commits
• should be discussed with the vdg.

Well, this change should be discussed with the vdg too in fact :)

In D3131#58136, @hpereiradacosta wrote:

Hello,
the idea is nice. For the implementation however, rather than changing the opacity of the painter, I think it would be more efficiency with changing the opacity of the colors that are passed to the various rendering methods instead.
As for the other design changes suggested in the comments:

• this should go to different commits
• should be discussed with the vdg. Well, this change should be discussed with the vdg too in fact :)

yes, this change is from a request by the VDG,
now, a good thing would be getting them to try it, but is always hard for c++ ;)

the latest version should use only color animations, removed all the painter opacity and the animation engine of breeze should be used in a more correct way.
a config option to enable/disable all of this is added.

In D3131#59062, @mart wrote:

• use the internal breeze animation machinery
• use the same graphics for the handle not under mouse
• scrollbar on mouse over is configurable

Sounds promising ! Code looks good. Will try the patch asap and review in more detail.

Hi Marco,

Couple of comments on the look of it

1/ if you set the animation time to somehting long (500ms), then hover on a scrollbar, in the groove, and not on the handle, while making sure that the view in which you hove does not have focus, in order to make sure that the handle is painted grey, not blue (either focus blue or hover blue), there is a glitch at the end of the animation where a somewhat too dark grey jumps to a lighter one. Must be some problem with transparency. Can you confirm, double check ? I 'think' this is also the case when you mouse-over the handle but this is less clear.

2/ I wonder whether the unhovered scrollbar of a focused view should use the focus blue for the handle (as it is now, without your change), instead of light grey. I at least was using is somewhat strong blue to easily catch the view that have focus, instead of the much more subtle blue outline. What do you think ?

3/ I agree that the animation looks good on views like dolphin and systemsettings. However for views with a header, or when you have both vertical and horizontal bars it looks stranger . But this is a matter of taste

4/ finally, I had this crazy idea :)
What if ... instead of making the groove "fade-in" on hover, we would make it "expand" vertically, from around the handle ? as if it would appear from under the handle and grow to ocupy the full height of the view ? Do you think it could look cool ?

In D3131#59202, @hpereiradacosta wrote:

Hi Marco,

Couple of comments on the look of it

1/ if you set the animation time to somehting long (500ms), then hover on a scrollbar, in the groove, and not on the handle, while making sure that the view in which you hove does not have focus, in order to make sure that the handle is painted grey, not blue (either focus blue or hover blue), there is a glitch at the end of the animation where a somewhat too dark grey jumps to a lighter one. Must be some problem with transparency. Can you confirm, double check ? I 'think' this is also the case when you mouse-over the handle but this is less clear.

yes, can reproduce, looking into that

2/ I wonder whether the unhovered scrollbar of a focused view should use the focus blue for the handle (as it is now, without your change), instead of light grey. I at least was using is somewhat strong blue to easily catch the view that have focus, instead of the much more subtle blue outline. What do you think ?

for me either way is fine, would like also vdg opinion on it

3/ I agree that the animation looks good on views like dolphin and systemsettings. However for views with a header, or when you have both vertical and horizontal bars it looks stranger . But this is a matter of taste

yeah, asked about this concern back them to vdg, they say basically that yeah, it's not that pretty, but better than nothing

4/ finally, I had this crazy idea :)
What if ... instead of making the groove "fade-in" on hover, we would make it "expand" vertically, from around the handle ? as if it would appear from under the handle and grow to ocupy the full height of the view ? Do you think it could look cool ?

may be cool.. (or also look a bit too jumpy) one thing, since i'm writing a qstyle-based theme for QtQuickControls2, this would make it harder to replicateon that weird qml/qstyle hybrid

In D3131#59202, @hpereiradacosta wrote:

Hi Marco,

Couple of comments on the look of it

1/ if you set the animation time to somehting long (500ms), then hover on a scrollbar, in the groove, and not on the handle, while making sure that the view in which you hove does not have focus, in order to make sure that the handle is painted grey, not blue (either focus blue or hover blue), there is a glitch at the end of the animation where a somewhat too dark grey jumps to a lighter one. Must be some problem with transparency. Can you confirm, double check ? I 'think' this is also the case when you mouse-over the handle but this is less clear.

that was because while animating the handle was drawn 2 times one on top of each other (as in the beginning the non mouse over was slimmer), now it just paints the same one, so it also has the proper color (blue on focus)

Awesome !
I just need some more time to look at the code, but as far as the visual aspect is concerned, I think its pretty cool.

In D3131#59205, @mart wrote:

In D3131#59202, @hpereiradacosta wrote:

3/ I agree that the animation looks good on views like dolphin and systemsettings. However for views with a header, or when you have both vertical and horizontal bars it looks stranger . But this is a matter of taste

yeah, asked about this concern back them to vdg, they say basically that yeah, it's not that pretty, but better than nothing

also should be minimized since iirc their intention is also to make the scrollbar a bit slimmer by default (painted around as wide as progressbars, maybe still with wider blank working mouse area but overall smaller

also should be minimized since iirc their intention is also to make the scrollbar a bit slimmer by default (painted around as wide as progressbars, maybe still with wider blank working mouse area but overall smaller

Just for my curiosity, where do these VDG discussions take place these days ? IRC ?

In D3131#59229, @hpereiradacosta wrote:

also should be minimized since iirc their intention is also to make the scrollbar a bit slimmer by default (painted around as wide as progressbars, maybe still with wider blank working mouse area but overall smaller

Just for my curiosity, where do these VDG discussions take place these days ? IRC ?

mostly Telegram https://telegram.me/vdgmainroom

relayed on irc too on #kde-vdg channel

Just added a couple of comments inline.
Also, (and somewhat out of topic), playing with the scrollbar width is rather easy: just change

ScrollBar_Extend,
ScrollBar_SliderWidth,
ScrollBar_MinSliderHeight

In breeze.h
I experienced with using 14, 6 and 6 for these dimensions, and the result is quite pleasing I think (6 is the progressbar groove width).
Feel free to commit this in a separate post if vdg is happy about it.
Now making this configurable is a complete different story, and in fact it is in "todo list" because ultimately, I think we want a slim (or compact) mode for breeze, to please people who complain about it wasting too much space.
(but this is completely out of topic :))

In D3131#59314, @hpereiradacosta wrote:

Just added a couple of comments inline.
Also, (and somewhat out of topic), playing with the scrollbar width is rather easy: just change

ScrollBar_Extend,
ScrollBar_SliderWidth,
ScrollBar_MinSliderHeight

In breeze.h
I experienced with using 14, 6 and 6 for these dimensions, and the result is quite pleasing I think (6 is the progressbar groove width).

In fact, 16, 6, 12 is better. A 6x6 handle is pretty hard to hit otherwise. And 16 for the width feels more confortable.

Hi Marco,
Two problems with the commit:
1/ it does not compile under kde4 (and we are still maintaining a kde4 and a kf5 version)

breezestyle.cpp:6652:26: error: ‘const class QStyleOptionSlider’ has no member named ‘styleObject’

else if( option->styleObject ) widgetMouseOver = option->styleObject->property("hover").toBool();

I can easily fix that.

2/ there are warnings:

/home/hpereira/kf5/src/kde/workspace/breeze/kstyle/breezestyle.cpp:6719:24: warning: unused variable ‘mouseOver’ [-Wunused-variable]

const bool mouseOver( ( option->state & State_MouseOver ) );
           ^

/home/hpereira/kf5/src/kde/workspace/breeze/kstyle/breezestyle.cpp:6724:18: warning: ‘widgetMouseOver’ may be used uninitialized in this function [-Wmaybe-uninitialized]

else if( !widgetMouseOver ) return Qt::transparent;

Here I think this is because the first mouseOver should be widgetMouseOver, but I am not sure. Can you double check ?

In D3131#59715, @hpereiradacosta wrote:

Hi Marco,
Two problems with the commit:
1/ it does not compile under kde4 (and we are still maintaining a kde4 and a kf5 version)

breezestyle.cpp:6652:26: error: ‘const class QStyleOptionSlider’ has no member named ‘styleObject’

else if( option->styleObject ) widgetMouseOver = option->styleObject->property("hover").toBool();

I can easily fix that.

2/ there are warnings:

/home/hpereira/kf5/src/kde/workspace/breeze/kstyle/breezestyle.cpp:6719:24: warning: unused variable ‘mouseOver’ [-Wunused-variable]

const bool mouseOver( ( option->state & State_MouseOver ) );
           ^

/home/hpereira/kf5/src/kde/workspace/breeze/kstyle/breezestyle.cpp:6724:18: warning: ‘widgetMouseOver’ may be used uninitialized in this function [-Wmaybe-uninitialized]

else if( !widgetMouseOver ) return Qt::transparent;

Here I think this is because the first mouseOver should be widgetMouseOver, but I am not sure. Can you double check ?

Looking more at the code, I think I am confused about the logic ...
How is widgetMouseOver different from mouseOver later on.
Why is one calling widget->mouseOver() and the second option->state & State_MouseOver ? (I would think the second is correct and should be used everywhere)

And finally, about the block on "disabled" state scrollbars, do we want the groove to show up on mouse-over in that case ? I think this tends to indicate that something will happen if you click, which is not the case ...

Sorry if I have not commented on this before the commit, I guess I must have not reviewed this part of the patch carefully enough.