-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
Scrollbar too slow to show, grab #3454
Comments
You know, I really want the scrollbar to have these options too. Actually getting the XAML scrollbar to behave that way was a lot tricker than we had originally hoped, but maybe we can still get this in. To clarify: this proposal is to have the scrollbar have three visibility states:
Right now we support "visible" and "hidden", but we want an "always" state added. If someone with more XAML experience would be willing to help us with this one, that'd be much appreciated. <technical details> From a internal mail thread back in April:
So we'll need to basically make a custom scrollbar template for the TermControl scrollbars. Not impossible, but certainly not easy. As another fun challenge, the TerminalControl project doesn't currently have any XAML files or resources, so we'd need to add those, or find a way to define them in TerminalApp and have them used by TermControl. EDIT: July 2020 update This will be substantially easier to do nowadays. As of late 2019, the TerminalControl project has XAML resources as well, so adding the appropriate XAML files shouldn't be that big of a pain. |
Can you push back on the XAML team or the OS team or somebody to make this behavior more accessible? I want always-visible scrollbars in the terminal, but I also want them in all programs that I use. Always visible-scrollbars are much faster to grab and use (as the original bug filter said), and they also give a visual indication of how big your document is, and where you are in it. And, I can't see any advantages to having them disappear - the disappearing doesn't give you more window space for text. |
The current XAML/WPF/whatever scrollbar thumb is also just way too small. My vision is good so I can see it but it's low-contrast and only about 2 pixels wide on both of my monitors. If it's going to collapse it should not be doing it in such a low-accessibility way. |
@randomascii If you want to make the scrollbar always visible for all programs, there is a setting under Ease of Access->Display, namely "Automatically hide scroll bars in Windows". You can just search and disable it. |
@randomascii Probably the best place to push for that would be filing an issue over in the WinUI repo. We'd definitely be willing to back up a request, though knowing what I know about their resourcing currently, it'd almost certainly be easier for us to add a custom templated scrollbar than for them to add the behavior we're looking for to the platform. This is at least in the near term - sure, the platform fix would be better for the ecosystem, but if you want a fix now for the terminal, doing it here is going to get you the fastest results. Fortunately, quite a bit has changed since November, and we've got quite a bit more XAML in our project than we used to. So I actually don't think that the changes that were outlined above would be terribly difficult to implement. I'd think the hardest part would be supporting both the current behavior and the requested behavior in one control class. It would probably be really easy to just have two control classes, and just instantiate one or the other. In fact, if we were able to get it figured out here, we'd probably be able to ingest the changes upstream in WinUI. |
Done |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This works, but it seems to only take effect for new instances of Windows Terminal. I think that existing instances of Windows Terminal should immediately respond when the value of this system-wide setting changes. And perhaps the title of this issue should be adjusted to reflect how the discussion has evolved? I would really like to be able to configure this per-profile, as per the idea above. But I've found that only "visible" and "hidden" are valid values. I'd like the ability to specify "always" for certain profiles, regardless of the value of the platform wide "Automatically hide scroll bars in Windows" setting in Ease of Access. |
It looks like that was fixed, and the Accessibility option is effective immediately and on existing windows now. |
This fixes #3454 by adding support for an "always" mode for the scroll bar. This change uses a custom VisualStateManager to keep the scroll bar from collapsing if the profile is using the 'always' setting. ## Validation Steps Performed Tried updating settings.json directly and using the UI and making sure the scroll bar behaves as expected. Closes #3454
🎉This issue was addressed in #14047, which has now been successfully released as Handy links: |
Environment
Problem (no steps)
Even with the default visibility of the scrollbar, it's too small to grab and the full size doesn't show fast enough - it's a productivity drain. Using my scroll wheel on my mouse is great when I have to scroll a few pages, but when I need to go back further in the output buffer I want to grab the scroll bar. Now, I have to wait a second or so before I can. Please give us a setting to always show it, like "hidden", "visible", or (new) "always" (or something like that). I want it always fully visible - at full size - ready to use like conhost.
The text was updated successfully, but these errors were encountered: