Page MenuHome

UI Experiment: Scrollbars
Needs ReviewPublic

Authored by Harley Acheson (harley) on Wed, Jan 1, 12:25 AM.



This patch is just an experiment in order to show a different possible behavior of the scrollbars. The incorporated change is not done in a way that could be accepted as-is - it is just hacked in. But could certainly be done better if we like this.

The issue this patch is illustrating is how the current hiding of the scrollbars also hides important details: your current position in the list and and estimation of how long the list is. It looks cleaner hiding the scrollbars but I'm not sure the current implementation is worth the loss of utility.

With this patch the scrollbars are always shown, if there is space to scroll. But does so at a reduced size and opacity. It is small enough to not get in the way or be distracting. But still large enough to indicate list position and length. Where the current scrollbars change opacity as your mouse gets closer to the edge, this version also increases the size of the scrollbars. This should make them easier to hit and use.

The following illustrates the changes in behavior. The top shows how it looks now. The left how Outliner might look when your mouse is not nearby, the right after the scrollbar appears.

The bottom shows how it looks after this patch is applied. The left how Outliner would always look with smaller scrollbar still indicating position in the list. The Right side shows the wider scrollbar while in use.

Diff Detail

rB Blender

Event Timeline

I've been playing with this for a bit. IMO this solution works quite well. You both get a very slim indicator when not interacting with the scroll bars, and you also get a larger scrollbar that's easier to grab when mousing over it.

I did run into a few instances where the scrollbars stopped expanding or contracting, but I will just assume that it's related to the fact that this implementation is more of a quick proof of concept hack job.

This revision is now accepted and ready to land.Wed, Jan 1, 12:19 PM

The idea is good, but after test in 2.82 it doesn't work properly. The scrollbar is wide when it must to be and thin when the mouse is over the scrollbar.

It appear to be pretty random the problem..

  • Sometimes is always thin, doesn't react to mouse position
  • Sometimes appear to add an offset to mouse position and when your are near to scrollbar it go back to thin
  • Soemtimes works good.

At least in my windows 10 instalation it happens and the change in behaviour depends of things like take and screenshot, move editors...

¿Maybe is a problem with old startup file?

@Alberto Velázquez (dcvertice) - ... it doesn't work properly....

No, I'd only expect it to work nicely most of the time or so. The purpose of this patch is just to illustrate this idea of having the scrollbars change in this manner. Describing it with words alone is quite often not enough to get a sense of something.

This implementation (as stated) is just quick and dirty. While the current code changes the opacity only, this patch uses that opacity value to also alter the width. But there are many times where the current code does not alter the opacity correctly at the times when it should. But these problems are far less noticeable now since it only affect opacity and scrollbars are often hidden.

So if we decide we like this behavior then I would take the time to implement this properly.

In that case the behaviour is perfect IMHO

No real functional changes.

Moving a few things into defines. Correcting scroll action zone sizes - for example vertical scrollbar should have action zone wider than its extent, but should not extend above and below, otherwise scrollbars in separate areas can overlap.

Note (mostly) to self. AFAIKT all the oddness that can happen with these scrollbar (now or with patch) comes from overlap between them.

When scrollbars are created they get an "action area" that is larger than they are and it is within that area that we test how close the mouse is. But for vertical scrollbars, for example, this space is not only wider but also higher and lower by the same amount. This means that two vertical scrollbars in different editors can interfere with each other. Which is why you can often control the Properties scrollbar visibility while in the Outliner area. Similarly, scrollbars in a single area will overlap with each other in a corner when it has both vertical and horizontal scrollbars. How it behaves in the overlap varies if it is between editors or inside a single one. Looks all fixable.

Now looking and behaving how I personally prefer it, which is always a nice starting point. I am no longer finding times when it stops working correctly. If you can reproduce any weirdness let me know. All comments are welcome though.

This is still not in a shape for review, only for testing to evaluate the behavior. Lets give it until the end of the month or so to decide if we like this better, or some variation, or hate it. If we like it then I can make this a bit nicer.

Campbell Barton (campbellbarton) requested changes to this revision.Sun, Jan 5, 5:37 AM

This introduces a bug:

  • Default startup file.
  • Duplicate all objects until outliner has vertical scroll-bar.
  • Hovering over the lower scroll-bar makes both scrollbars size increase.
  • Hovering over the right scroll-bar doesn't do anything.
This revision now requires changes to proceed.Sun, Jan 5, 5:37 AM

@Campbell Barton (campbellbarton) I cannot reproduce your issue. I've done your steps dozens of times, but it seems to work as expected.

Are you sure you are using Harley's latest patch?

Another note to self is that there is inconsistent usage of V2D_SCROLL_HEIGHT versus WIDTH with some places assuming the width one just means size and using it in places where they should use height. Both values are the same, so if we did want to globally make vertical scrollbars be wider than horizontal ones are high, then many would not change as expected. Could fix these or just change to using one size define instead of two since I’d doubt we’d ever want them different anyway.

Also, scrollbar outline theme color needs to be RBGA. Right now can’t be made invisible, and has inconsistent look over different backgrounds. The other parts all have alpha component.

Turned off scrollbar outline and embossing because this is just an experiment and both me and William hate the scrollbar outline and embossing. LOL

Julian Eisel (Severin) requested changes to this revision.Thu, Jan 16, 8:47 PM

Generally I think this is a great improvement! Definitely +1 for continuing work.

Found some issues which don't seem to be known:

  • In the outliner the behavior is very glitchy, similar to what Campbell describes. It seems like the "hotspot" (AZone) is only using the inner scroll rectangle (the one indicating the current scrolling), not the full region height. This does *not* happen with a newly created outliner, or after forcing a re-init by dragging a area separator. So this is probably some V2D flag state issue.
  • The changing height of horizontal scrollbars also changes the position of the vertical scrollbar: (player controls overlap the important part again...) I think if there's a horizontal scrollbar the vertical one should just always be offset by the max height of the horizontal one.
  • This basically brings back the super thick scrollbars to the uiLists, not sure if that's something we should do. We could "animate" them there too, see V2D_SCROLL_WIDTH usages in uiTemplateList().
  • I get this is personal taste, but I find the full size scrollbar just a tad too bold now :) Maybe reduce size by 2-3 pixels.

Let me know if you could use another pair of eyes to debug/finish this.

This revision now requires changes to proceed.Thu, Jan 16, 8:47 PM

Thanks again @Julian Eisel (Severin) !

Yes, I have a feeling that I will end getting stuck with this one. The bones of the idea seems simple enough but these oddities, like in Outliner, are hard to track down. But I get back next week so I can spend more time exploring as I know how busy you are.

Debuk (Debuk) added a subscriber: Debuk (Debuk).EditedWed, Jan 22, 11:36 AM
  1. @Campbell Barton (campbellbarton): No I dont think these glitches were introduced by this patch. These already exist.
    • Default startup file.
    • Duplicate all objects until outliner has vertical scroll-bar.
    • Hovering over the right scroll-bar
      • doesn't do anything if you are in the upper part of the outliner and move the mouse towards the right side
      • works from a specific point on below y wise
  1. The nonworking area in the upper part increases the more vertical space the outliner has in the beginning.
    • Default startup file.
    • Resize outliner vertically
    • Duplicate all objects until outliner has vertical scroll-bar.
    • ...
  2. If you make the outliner area wider *BEFORE* duplicating objects then it does no longer work at all until the area has been resized again. So if you resize the area the glitch is gone.
    • Default startup file.
    • Resize outliner horizontally
    • Duplicate all objects until outliner has vertical scroll-bar.
    • ...

This is the current behaviour without this patch applied. I Also tested with 2.80 aswell as the current alpha!

Animated Gif. Wide outliner glitch and Tall outliner glitch

Managed to find where it was adjusting the lower position of vertical scrollbars when the height of a horizontal one in same area changes.

Otherwise not making much headway so far.