mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #657] Suggestion: provide visual feedback in main barrier window if scroll lock is on (cursor locked to screen) #517
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#517
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @XertroV on GitHub (May 7, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/657
Spent a good 10 minutes trying to figure out why things weren't working (after a slightly rocky getting connected dance). The ONLY feedback given to the user to indicate scroll lock will lock the cursor to the screen is ONE LINE IN THE LOG, which I only noticed because I had the log open from the connection troubles.
There is nothing in any of the 3 tabs of 'configure server' (two of which are 'hotkeys' and 'advanced'). TBH I'd say at this stage it's more important not to ruin someone's experience than to have a silent scroll-lock feature. But the better soln is just to put a status msg somewhere.
Barrier is great -- now. It would have been a shame if I'd given up a few min earlier just because there wasn't little red msg on the server status page.
@wrgrant commented on GitHub (Sep 19, 2020):
Yes. This is bad UX. Hidden features = frustrating.
Just disable the hard coded ScrollLock binding.
If someone wants to enable this feature they can setup a hotkey.
@bsdfirst commented on GitHub (Oct 23, 2020):
After a bunch of frustration and the subsequent discovery of the same "ONE LINE IN THE LOG", I was about to go read the source code when I found this. Scroll-lock. Sigh.
@hrafnkelle commented on GitHub (Nov 6, 2020):
Glad I found this thread. I was going mad. Had to enable DEBUG1 to see "locked to screen" and could then find this. Please make this more visible.
@sargon2 commented on GitHub (Jan 26, 2021):
+1. I just ran into this. Very frustrating trying to figure out why Barrier is not working when it should be. I even checked "hotkeys" to see if I had a hotkey set up that might be breaking it, and the list was empty.
@dnunes commented on GitHub (Mar 1, 2021):
I also had this problem for a while before taking the time to check the logs in Debug 2 mode, but even then the "Locked to screen" is not very helpful because it doesn't say why. I had to do a Google Search to get here and find out the ScrollLock was the culprit. I don't even know how to toggle my ScrollLock on my computer as I don't have that key anymore for years now, so I had to go into the On-screen Keyboard to deactivate it.
Please just disable this behavior or add some information about it somewhere (a visual indicator on the main screen would be enough). At the absolute very minimum, change the log message to "Locked to Screen because ScrollLock is active" or something and maybe move it to "Debug" level.
@breakingspell commented on GitHub (Mar 1, 2021):
Agreed that this behavior should be reworked. I use Scroll Lock as a toggle for AHK scripts, it made Barrier seem unreliable when it was operating as designed.
To confirm, setting another hotkey for lockCursorToScreen (Alt+Shift+Scroll Lock in my case) takes the binding off of Scroll Lock by itself, but some kind of indicator for the cursor lock (OSD, systray) would be superb.
@stevleibelt commented on GitHub (Jun 23, 2021):
Thank you very much @XertroV for this post.
As 100 percent of the others, I came here by browsing the issue list searching for "locked to screen".
I must admit, I am not using the "scroll lock" (in german "Rollen") key at all. That's why it took me so long to figure out this key was pressed (by mistake).
@p12tic commented on GitHub (Jun 25, 2021):
I would say that this behavior is so confusing that it makes sense to call it a bug.
@coolspot18 commented on GitHub (Feb 9, 2022):
What do do if scroll lock is actually needed like in Microsoft Excel?
@mirh commented on GitHub (Feb 25, 2022):
Then you are probably interested to #1252 or #435
This bug instead is a duplicate of #482