Was talking to @William Reynish (billreynish) and we thought we'd try this change. Since the scrollbars are always visible, there is no need to have such a wide runoff distance to gradually show them at full-width and full-opacity. This uses a bare-minimum distance, so you are are almost on top of them before they grow, but they still do so in a smooth fashion.

Will also update the animation in the first post.

By showing the scrollbars all the time (although narrow and faded) it does expose some existing issues with scrollbars. I think we'd have to consider the following first:

• https://developer.blender.org/D10709
• https://developer.blender.org/D10733

I was suggested by a User on the RCS forums to highlight my suggestion as it pertains to scrollbars https://blender.community/c/rightclickselect/Ryhbbc/#60ba3a6f9c12210e7d5795b2
In short: I encountered a problem when fiddling with certain values like the curve editors. That when i'm trying to control the last point on a curve i'll accidentally move the whole window up cause i hit the scrollbar.

Some sorta light margin would be good. Or making the scrollbar slightly thicker

This patch has come a long way! Just tested it now and it feels pretty good.

I've got some notes regarding the looks/theme of the (I call global) scrollbars, the UILists and the 2D viewport scrollbars. The default theme needs to be adjusted for sure, that can be done immediately after the patch goes to master. However I see some hardcoded values and how we could make better use of existing theme settings.

• The default transparency of the scrollbars is hardcoded, this makes them hard to theme
  • Notice how the scrollbar thumb looks purple because the track is red and thumb is blue
  • 
  • Both theme settings inner and item support transparency, we can use that instead of hardcoded values.
  • Transparency is currently used to indicate active/hover state. I noticed the inner_sel property is not being used, maybe we can blend to that? (which also supports alpha!)
• The full width of the hovered scrollbar could match the width of 2D scrollbars (by making the 2D scrollbars a few pixels smaller)
  • 
• Theme outline setting is only used on UI Lists scrollbars. I would say we go for consistency and match the global scrollbars style so disable outlines there. I know UILists are a separate topic but they could at least match in width the hovered global scrollbars.

@Pablo Vazquez (pablovazquez) - Notice how the scrollbar thumb looks purple because the track is red and thumb is blue

Hmm.... but this is how the theming of scrollbars work right now. With current master if you set the theme as you show with blue on red you will see purple as it fades in:

In D6505#319514, @Harley Acheson (harley) wrote:

@Pablo Vazquez (pablovazquez) - Notice how the scrollbar thumb looks purple because the track is red and thumb is blue

Hmm.... but this is how the theming of scrollbars work right now. With current master if you set the theme as you show with blue on red you will see purple as it fades in:

Yes. My bad, I saw this patch as a more general refactor of scrollbars and not just the change on show/hide behavior.

The fact that they will be always present highlights this problem so I tried to give feedback on that, so let's get this patch into master and start a task about scrollbar looks :D

What else is missing to move on with this? Seems like with the patches you included this is mostly good to go?

@Pablo Vazquez (pablovazquez) - Seems like with the patches you included this is mostly good to go?

All the other patches in my pile are quite simple and safe, but this one has pitfalls and is the least likely to make it in. It is more like we need to start with a commitment to showing scrollbars this way and then move forward. This idea was something me and William had wanted for 2.8.

As you've seen, showing them all the time makes it more likely that errors are noticed and complained about. That is not only with the case with the theme settings, but also the reason why this patch had to incorporate the scrollbar fixes by @Anthony Edlin (krash) (D10709 & D10733). Those two fixes would need to be considered on their own and approved separately. But by someone familiar enough with this area of code to approve, so might require Campbell, Brecht, or Julian. It is certainly possible that @Hans Goudey (HooglyBoogly) could look at them and say "yes, that makes sense", but just saying that they are mysterious to me. But if they had a quick look by someone else I could commit with krash as author.

Then I could refactor this and (hopefully) simplify some of the dumber calculations in this patch. It is currently just bolting onto the existing v2d->alpha_* calculations so could be made more understandable.

With all this done though we could still get more complaints about things not looking quite right just because these are more visible more often. So there would be pressure to make UILists look similar, or make changes to them in timeline, etc. Although much of that could be done by volunteers. We just can't assume that anything else would be done before 3.0 release.

Applied these changes and now its possible to fade out the ScrollBar Outline.

blender 3.0 Scrollbar Item Alpha= 0, Outline still visible ( ScrollBar Outline Color matched to the Timeline BG Color but you see the Scrollbar outline as there is no Alpha Value for Outline )

With the above code changes the ScrollBar Outline Alpha is controlled by the Item Alpha
With ScrollBar Item Alpha=1

With ScrollBar Item Alpha=0

Cannot comment on the ScrollBar behavior as I generally turn them off.

These changes makes the Timelline and Graph Editor very clean if a user wants to change the Defaults. It still provides visual feedback to where the user is by looking at the dots.

Looks interesting, but not sure about thickening - your final aim point is different from the initial.
It also still takes efforts to search opaque element's location and size that indicates your location in a list, especially if to take into account UI elements overlapping.

In D6505#347807, @Harley Acheson (harley) wrote:

If "feels" better than it describes. I just updated the patch so that it applies easily against the current state of master, so you can give it a try if you haven't yet.

It is definitely a better solution - visible scrollbars are needed for long list using which is quite common in Blender.
The efficiency can be checked only during extensive use in my opinion.

Just make an option to make it

1. fixed width (defined by user)
2. always visible

@Pablo Vazquez (pablovazquez) - Accepting from the UI side of things. Code wise I leave it to @Julian Eisel (Severin) or others.

I'd be okay with getting this in, but only very early in a release. I myself would commit in three parts, so with D10709 and D10733 attributed to krash as those changes are needed but can live on their own. I'd just approve those with myself as only reviewer and point at this patch for reasoning.

Outside of the addition of D10709 and D10733 there hasn't been much change since Julian gave a LGTM. Campbell though hasn't looked at it in a while - he noticed lots of issues that have since been fixed by krash's patches.

If we do this I think someone (probably me) should afterward refactor v2d's alpha_hor and alpha_vert as their names won't match their usages. Might be a way to simplify those too.

Updating for review

Confirmed that this version still fixes T72392: Resizing Outliner and Properties editor windows makes the outliner view go up if its long enough. and T75003: Outliner scrollbar does not appear with resolutions greater than FHD, since it incorporates D10709: Fix T72392: Resizing Outliner and Properties editor windows makes the outliner view go up. and D10733: Fix T75003: Scrollbars hidden on file load.. Checking because we decided to not change V2D_COMMONVIEW_LIST to V2D_COMMONVIEW_CUSTOM in interface_region_hud.c.

As you can see, the original version of D10709: Fix T72392: Resizing Outliner and Properties editor windows makes the outliner view go up. didn't include the COMMONVIEW_LIST change or the region->v2d.maxzoom = 1.0f lines, but was added because it broke the last operator settings, so your testing should be around that. Obviously that was over a year ago and may not be the case anymore, but I do remember adding it for a reason. I think it was because hud regions kinda abused region system to fit something it wasn't initially designed for. I will check it out but I recently had a total hard drive failure and need to re-setup building blender and haven't had time recently.

@Anthony Edlin (krash) - but I do remember adding it for a reason...

For sure. Its just that me and Campbell couldn't find anything that broke without it. So many little edge cases here. Yikes.

I will check it out but I recently had a total hard drive failure and need to re-setup building blender and haven't had time recently.

That would be great. We are relying on you for help here, I'm afraid.

In D6505#350296, @wasd (arcticwasd) wrote:

Just make an option to make it

1. fixed width (defined by user)
2. always visible

Yes, there is a quite a strong design process problem - designing secondary UI elements.
The problem is that when designing secondary user interface elements, you pay much more attention to them than when you use them in normal work (you usually pay 99% of attention to design an element which has to be recognisable with 1% of attention during working process), so you may think that transparency, invisibility and other effects are looking cool.
But the only functional purpose of a secondary element is to be available and recognisable as fast as it is technically possible for human perception speed - to not to exceed 1% attention requirement, otherwise it forms a workflow issue.

Satisfying such a conditions assumes:

• No invisibility so you don't have to play infinite exhausting hide-and seek with a program you use.
• No transparency so you don't have to search barely visible elements on the screen what you supposed to see.
• No effects (jiggling, jumping, resizing, transparencing, ) or similar stuff so you don't have to refine the cursor especially when you aiming the borders.

After all, Blender is not a browser or video/audio player - it is a software for work with very flexible and customizable interface, and its flexibility has to be compensated with visual stability of a secondary UI elements.
There better be such an option available, compatible with fast work/interface navigation.