Scrollbar behavior change

[wolfpld]

Version/Branch of Dear ImGui:

Back-ends:

Compiler, OS:

Full config/build information:

No response

Details:

#7328 resulted in a change to the scrollbar behavior. The new behavior is not satisfactory. Is there a way to choose to have the old behavior instead?

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

No response

[ocornut]

Can you clarify a bit how unsatisfactory it is?
When click dragging from the grab the old behavior is still available.

[wolfpld]

It's very annoying and losses functionality.

To give this some background, I am using the "scroll to place clicked" (the old ImGui behavior) system-wide on my PC and I find it a great improvement over the "click to page up/down" behavior. This seems to be a general consensus, as all sorts of applications are shifting into this direction (i.e. GTK3 for 10+ years now, it's the default in KDE 6, and the default in VS Code). So, seeing ImGui go in a reverse direction, and with no switch available to change it back is a bit sad.

The original issue seems to miss that there are page up/down keys, which do exactly what's requested - move the displayed content page up or down.

As for the loss of functionality, I am no longer able to click on a hot-spot overlaid over the scroll bar to go directly to it. I now have to fish for the scroll bar, carefully move the mouse over it and grab it, then move it over the area I am interested in. This is much more finicky than just clicking on where I want to be.

[ocornut]

Probably I was too fast jumping on that bandwagon, and I understand that in particular if you have a scrollbar overlay you would like really want the old behavior.

Probably we should support both, which opens two questions:

• which one is the better default.
• how to select them? do we support changing the setting per-window (probably yes), do we encourage it (probably not) ?

[ocornut]

I am using the "scroll to place clicked" (the old ImGui behavior) system-wide on my PC

Where is the option for this and what it is called? it is standardized and pulled by all apps? or a per-app setting? I assume you are on Linux? If it is a standardized settings, would it make sense to attempt to set default based on settings, if they are easy/standard to access?

as all sorts of applications are shifting into this direction (i.e. GTK3 for 10+ years now, it's the default in KDE 6, and the default in VS Code). So, seeing ImGui go in a reverse direction, and with no switch available to change it back is a bit sad.

Effectively every application I currently use on my Windows PC does the per page scroll: Firefox, Visual Studio, Discord, Explorer, Sublime, Git Fork. So I don't know, maybe it is a Linux trend?

To clarify, we will find a way to allow both behaviors, but I'm pointing this to understand what's the better default.

[ocornut]

While researching this I have learned that Shift+Clicking on a scrollbar in Windows always use the previous absolute-seeking behavior that you like/want. I have implemented that now as a727332 since it seems standard in Windows land.

I am still open to provide an option to always enable this (still interested in your answer to the questions above).

[wolfpld]

Probably we should support both, which opens two questions:

I guess it's a matter of question how deep you want to go with customizability. I would be fine even with a compile-time option, as that's basically the status quo.

Where is the option for this and what it is called? it is standardized and pulled by all apps? or a per-app setting? I assume you are on Linux? If it is a standardized settings, would it make sense to attempt to set default based on settings, if they are easy/standard to access?

In KDE you can find it in "General Behavior" in System Settings. It seems to control the behavior in all QT applications, as I see this in Qualculate, which is not an KDE program.

I don't know if it's standarized. Probably it's the usual jumble of per-toolkit config dot files. In VS Code this is controlled by editor.scrollbar.scrollByPage and workbench.list.scrollByPage settings, with the notable omission of a setting for the minimap. In Firefox the behavior is an artifact of how GTK3 behaves. In Steam and Signal I see the behavior is scrolling a page.

[ocornut]

In addition to shift+click support (scrolls to the clicked location), I have added with fb41046 a new setting io.ConfigScrollbarScrollByPage=true which you can set back to false to always do that.

This is only used by the Scrollbar widget so you can technically alter it temporarily for a specific window if you need.

let me know if that works for you!

[wolfpld]

It seems to be working all right, thanks!