Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behavior of clicking in scrollbar #7328

Closed
m9710797 opened this issue Feb 17, 2024 · 3 comments
Closed

Behavior of clicking in scrollbar #7328

m9710797 opened this issue Feb 17, 2024 · 3 comments

Comments

@m9710797
Copy link

Version/Branch of Dear ImGui:

Version 1.90.3, Branch: docking

Back-ends:

imgui_impl_opengl3.cpp + imgui_impl_sdl2.cpp

Compiler, OS:

Linux + GCC 13

Full config/build information:

No response

Details:

Hi,

Applications typically react in one of two ways when clicking in a scrollbar:

  • The scrollbar-slider is immediately moved to that position. This is the behavior that Dear ImGui currently implements. And for example visual studio code does the same.
  • Clicking above or below the slider scrolls up/down one page. Clicking on the slider allows to drag it up/down. For example firefox and chrome implement this behavior (or does it depend on the OS and/or window-manager?).

Depending on the situation one or the other can be better.

For example in my application (using Dear ImGui) I have a debugger with a disassembly view. This view literally contains tens of thousands of instructions (thanks a lot for ImGuiListClipper!). Trying to accurately scroll in this view using the scrollbar is difficult. And therefor some of our users requested the alternative scrollbar behavior.

The current workaround (for positioning the view using the mouse) is to approximately scroll via clicking the scrollbar and then fine-tune via the scroll-wheel. Though that's not ideal. Allowing to scroll per-page with the mouse (like in firefox/chrome) would mitigate this problem.

My question: would it be possible to have this alternative behavior for ImGui scrollbars?

  • Either by manually coding/customizing the behavior. Could you then give some hints for how this could be done?
  • Or by implementing this behavior in Dear ImGui itself. And then either have this globally selectable or per child window via a new ImGuiChildFlag? (Though I've not yet encountered an application that uses a mix of both behaviors).

An orthogonal though related question:
Some application use CTRL+scroll-wheel to scroll per page instead of per line. Could that be added in Dear ImGui? Though this behavior seems less universal, some applications instead zoom in/out when using CTRL+scroll-wheel.

Thanks for considering this.

Wouter

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

No response

ocornut added a commit that referenced this issue May 28, 2024
…ing mouse button repeats scrolling. (#7328, #150)

Remove absolute seeking entirely. Amend f021080.
@ocornut
Copy link
Owner

ocornut commented May 28, 2024

I have reworked the scrollbar behavior as suggested, doing a page by page scroll when clicking outside the grab: 5cbc34a

Some application use CTRL+scroll-wheel to scroll per page instead of per line. Could that be added in Dear ImGui? Though this > behavior seems less universal, some applications instead zoom in/out when using CTRL+scroll-wheel.

That may be implemented on your end:

if (ImGui::Shortcut(ImGuiMod_Ctrl | ImGuiKey_MouseWheelY))
{
    float v = ImGui::GetKeyData(ImGuiKey_MouseWheelY)->AnalogValue;
    ImGui::SetScrollY(ImGui::GetScrollY() + -v * ImGui::GetCurrentWindow()->InnerRect.GetHeight());
}

HOWEVER, it won't work as expected/desired with OS and drivers emitting smooth scrolling values for wheel (such as OS X, and some mouse setups/drivers on Windows).

@ocornut ocornut closed this as completed May 28, 2024
@m9710797
Copy link
Author

Thanks!
I'll try it soon.

m9710797 added a commit to openMSX/openMSX that referenced this issue Jun 3, 2024
The main motivation for upgrading is:
    ocornut/imgui#7328
Thanks 'ocornut' for implementing this!

After upgrading (to v1.90.7) we needed to adjust for some API changes:
    #1630
Thanks again 'ocornut' for the heads-up.
@m9710797
Copy link
Author

m9710797 commented Jun 3, 2024

It's working great. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants