Use reserved scroll mode for inspector

[KoBeWi]

Prevents content jumping when scroll bar appears, at the cost of some horizontal space when the scroll bar is invisible.

Before	After

[Calinou]

Makes sense to me.

We should check if this UX pattern should be reused elsewhere in the editor. There are likely other locations where it's worth using to avoid sudden jumps in UI layout.

[arkology]

This is great that content "jumping" was removed, but when there is no scrollbar this empty space from one side looks... strange. And also content width is always (not depend on scrollbar visibility) reduced.

4.4stable or master	This PR

UPD:
I looked how some IDEs and browsers handles this. They do not show it at all when it is not needed or show it as disabled.

[KoBeWi]

There is also an option to always show the ScrollBar. It removes the empty space at least:

And also content width is always (not depend on scrollbar visibility) reduced.

In practice the scrollbar is visible most of the time anyway, so the extra space was at most temporary.

[Calinou]

There is also an option to always show the ScrollBar. It removes the empty space at least:

The tall scrollbar looks odd to me (and a bit distracting), so I'd prefer not. In terms of UX, it's also not ideal to show a scrollbar when no scrolling is possible.

[arkology]

In practice the scrollbar is visible most of the time anyway, so the extra space was at most temporary.

So content jumping prevented by this PR will almost never happen)

I do not have strong opinion about this, so... maybe just merge it for next dev build (that's what dev builds are for, right?). I’m not sure if there are other convenient ways to gather feedback from a large number of users.

[akien-mga]

I expect there would be quite some pushback from users if we merge this, the empty space looks pretty big.
Would be good to collect more feedback on this and potential other options from UX minded people (cc @passivestar @RY-Storm).

One alternative option would be to do like browsers do (at least GTK based ones on Linux) and make the scrollbar invisible by default, and show it on hover as an overlay on the content:

(Though I'm not sure what's up with this three-state UX pattern, and I personally find it often frustrating that scrollbars are invisible/thin and thus hard to grab, but this issue shows why that might be a good option anyway.)

[Zireael07]

and I personally find it often frustrating that scrollbars are invisible/thin and thus hard to grab

This very much. If they do that, I want them to be big!

[RY-Storm]

Thanks for the tag @akien-mga!

show it on hover as an overlay on the content

I think what you say here is what would please the most folks.

In a nutshell, from a UX standpoint, what I think would work well is:

• Have the scrollbar be an overlay over the content, so that content does not jump, and no deadspace exists when it is invisible
• Have the initial scrollbar be thin, so it is not obtrusive
• Make the scrollbar thicker when it is hovered over directly, with some leeway on either side, for accessibility of the scrollbar, both visually and as an area to grab.
• Do not show a scrollbar when the window cannot be scrolled. (No full-length scrollbar)

With an option of two paths for UX:

• Show the scrollbar when the window is hovered over
  or
• Show the scrollbar when the mouse is hovering near it, at the edge of the window, and when scrolling is triggered in any way

[RY-Storm]

And I would be remiss if I didn't show myself following my own advice of: "Always look at what is out there.", so here are some gifs of examples:

Unity:

The content jumps

Unreal:

The content jumps

LibreOffice Writer:

The content does not jump, but the scrollbar is always visible, so it may cover content.

OBS:

The content does not jump, but the scrollbar is always visible, so it may cover content.

I think theses examples reinforce what I mentioned in the above comment:
Only show the scrollbar when hovering near it, and only show it when it can be used.

[passivestar]

I agree that showing scrollbar as an overlay on hover is the cleanest solution, blender is doing the same btw:

blenderscrollbar.mp4

The empty space reserved for the scrollbar in this PR does look a little weird to me, especially with godot's default theme that draws a visible border around the tree, making that empty space more noticeable

Overall I think draggable scrollbar is more of an accessibility feature than an essential one. It was unavoidable in the past when most mainstream mice didn't have a scrollwheel. Grabbing the scrollbar is always slower than using a scrollwheel even if the scrollbar is big, just like every interaction that needs aim. It makes sense for it to stay hidden/narrow most of the time and serve mostly as an indicator

[arkology]

Overall I think draggable scrollbar is more of an accessibility feature than an essential one. It was unavoidable in the past when most mainstream mice didn't have a scrollwheel. Grabbing the scrollbar is always slower than using a scrollwheel even if the scrollbar is big, just like every interaction that needs aim.

Godot also has Android version. On Android navigation using scrollbar in Godot is main option (in terms of usability, at least for me). Also it has significantly increased width.

[passivestar]

Godot also has Android version. On Android navigation using scrollbar in Godot is main option (in terms of usability, at least for me). Also it has significantly increased width

I remember, I think it should be draggable anywhere on the scroll container and only draw a narrow scroll indicator. Just like scrolling is done in all mobile apps

[arkology]

It is draggable, but in most cases leads to missclicks and incidental pressing buttons, unfolding categories etc.

[passivestar]

It needs better drag detection then because it works well in other mobile apps

After all mobile is the worst platform to draw big scrollbars on because of the small screen size

[avedar]

I agree that showing scrollbar as an overlay on hover is the cleanest solution, blender is doing the same btw:
blenderscrollbar.mp4

To be clear, Blender is doing a mix of several things in this video which all feel pretty reasonable:

1. Very narrow reserved/scrollbar space
2. Scrollbar only visible when scrollable
3. Only scrollbar grows on hover

The key being it's probably using the narrowest amount of reserved space possible

[KoBeWi]

Something like this?

godot.windows.editor.dev.x86_64_jIAop6GfWv.mp4

The scrollbar still reserves space, but only 20%.

[passivestar]

Something like this?

yes but the right edge of the scrollbar should stay in place when the scrollbar enlarges imo to make sure mouse cursor is still over the scrollbar when that happens, because you normally wouldn't expect a ui element to be clickable/draggable when it's not under the cursor. I also think it could be a bit thicker by default, it appears to be only 1px in the video. blender video that I posted is probably a good reference for both of those things

The scrollbar still reserves space, but only 20%

it's fine, can be further improved in the future by evening out all of the gaps around the scrollable area (by making left/top/right gaps same size) to make the scrollbar space on the right "invisible" when the scrollbar is hidden

[RY-Storm]

right edge of the scrollbar should stay in place when the scrollbar enlarges imo

Agreed, the Blender example of it growing while its right edge stays put inside the reserved area is good.
In the video above the scrollbar looks like it 'runs away' from the mouse, as it moves left entirely.

One other thing that would be good to check is: On the triple dot menus and dropdowns in the above video: Does moving the mouse over them trigger the scrollbar too enlarge, and cover the element? That would be frustrating.

[KoBeWi]

the right edge of the scrollbar should stay in place when the scrollbar enlarges

The right edge stays in place. The scrollbar is scaled, but it looks like it's being moved because of rounded corners. I made the scrollbar appear when cursor is over the area covered by its full size.

Not sure if this can be improved much without changing the scrollbar style.

[Calinou]

Hidden scrollbars are typically 2 * EDSCALE pixels thick in most apps.

Regarding scrollbars on mobile, most of them don't have any interactivity, except for large list collections (e.g. most music players allow interacting with their scroll bar to browse collections).

[KoBeWi]

I realized the reserved space creates double margin - the inspector's default one + the space for ScrollBar. I just removed the default one and it looks better. Note that the behavior is a bit bugged right now and does not expand/shrink when expected yet.

godot.windows.editor.dev.x86_64_hzpp9mlv5k.mp4

[KoBeWi]

Pushed the ScrollBar shrink feature. It's a bit bugged though, I will have to fix it.