Can't scroll on the right of the stylus when the sidebar is on the right while hovering
Heiseneberg-maybe opened this issue · comments
Describe the bug
When hovering with a stylus the right side of the screen is blocked from receiving touch inputs even when the sidebar is set to be on the right side. This means that left-handed people have to use the left part of the screen to move the canvas with touch input, which is quite uncomfortable.
To Reproduce
- Set the sidebar to the right
- Write something using the left hand
- Scroll the canvas on the right of where you wrote(while hovering with the stylus where you finished writing)
- You aren't able to do 3
Expected behavior
The ideal solution would be to block the inputs from where the hand is present and add a padding to that area. For this to be possible there should be in every moment a check of where the hand is and a padding should be added to that area.
I think that this is not trivial to do and that it might add complexity to the code and on top of that it might even reduce the performance of the app. (You're developer tho so you know this better than me for sure).
The pro to having this implementation is that you could move the canvas using one of the fingers of the hand with which you're holding the stylus.
The solution that I think is more appropriate is to do the same thing as of now but mirrored when the sidebar is set to the left of the screen(supposing that only left-handed people would put the sidebar on the right and assuming that only right-handed people would put the sidebar on the left).
This means that (when the sidebar is on the right)the inputs should be blocked on the left side of the screen starting from a bit right (in order to add a padding) of the point in which the "Regular cursor" is present in the canvas.
Screenshots
Desktop (please complete the following information):
Not related to the desktop
Additional context
This bug was discovered in #313, I would really advise reading it to properly understand the scenario.
This is the situation for me right now.
Let me discuss all my queries and issues from #313
Also, let me add some more context,
- I am right-handed
- When I write using my stylus, I am using my left hand to scroll
- In gnome-tweaks, I have set window titlebar buttons on the left
- My sidebar is on the left side
Are you sure that it is only specific regions where the touch dragging does not work while hovering with the stylus?
On my 2in1 hovering also blocks the touch input, but everywhere (the stylus has to be very close to the surface, and stay in motion a little bit to keep the hovering state ). And my guess is that all input events get consumed by the stylus "gesture" when it detects the hover instead of letting touch events through to the touch drag gesture.
I also have to say it is debatable if it even is desired to allow touch input while hovering. My personal flow is that i usually lift the pen and drag with the pinky of my writing hand. However my stylus goes out of the hover very quickly, I can see that it is annoying when it takes some time.
I also have to say it is debatable if it even is desired to allow touch input while hovering. My personal flow is that i usually lift the pen and drag with the pinky of my writing hand.
I kind of agree with you on this part. When I was on windows, accidental strokes from touch were really annoying. There really is no need to include complicated features when the current workflow works perfectly fine for the most part.
Are you sure that it is only specific regions where the touch dragging does not work while hovering with the stylus?
On my 2in1 hovering also blocks the touch input, but everywhere (the stylus has to be very close to the surface, and stay in motion a little bit to keep the hovering state ).
Yes, there is no touch input when the stylus is on hover, not just specific regions.
Alright, this is the behavior I'm having
https://user-images.githubusercontent.com/104737846/198734692-aff4655f-4ef1-4621-aaf6-ec74b9bc177e.mp4
Being that you both have the same behaviour (which is different from mine) it seems like I am the one experiencing a bug.
I'm sorry for creating confusion in #313 and here.
I think that the bug is well documented here and in #313, but if you want I'll create a new issue (closing this one) or modify this one
I think we should properly document this issue first. The issue from #313 was me requesting a kind of toggle to use the stylus as pointer but there's already such feature available. So it's better that that issue is closed.
As for this behavior, can you tell us what's the scenario following is true
- window topbar button(s) on the left
- a custom gtk theme is applied
- all your extensions are turned off
- if your laptop is a 2in1, does this behavior persists in tablet mode?
This behaviour persists with all extensions turned off, with no changes to the topbar buttons and without a custom gtk theme.
Regarding the tablet mode of my 2in1, I actually have a problem with it: I had to send the computer to repair this summer and since it came back the touchpad and the keyboard don't turn off anymore when the screen is flipped, it does however go into tablet mode in Windows. I wasn't able to reactivate the tablet mode on Linux yet(even with a new installation).
I suppose that @flxzt knows if Rnote registers the fact that the computer is in tablet mode and behaves differently if it is.
The video is showing it pretty clearly, thanks! I currently don't really know what is going on there, Rnote itself does not block / allow input from specific regions on the canvas, so it must be the behaviour of GTK or even the input driver (maybe it is supposed to be palm rejection where on some devices it blocks touch input completely (like mine), on some devices only a specific region (like yours) )
My first guess also seems to be incorrect, your video clearly shows both stylus and touch input at the same time.
I too think that it is supposed to be palm rejection.
I checked various applications and I found out that:
Xournal++ and Inkscape block the inputs in the same way that is shown in the video. (Both are written in Gtk)
Openboard and Drawing do not block any input. (Written in Qt and Gtk respectively)
I am not quite sure what to deduce from this, it might be a mixture of the behaviour of GTK and the behaviour of the input driver(assuming these apps( similarly to Rnote) don't block areas of the canvas )
Considering that I am not bothered by the behaviour shown in the video, that the bug doesn't seem to be Rnote's fault and that left-handed people would just experience the app like you two do, which is in the expected way, I would consider this issue closed.
I agree that there is probably not much to be done on the app side, but other users will probably stumble upon the same issue, so lets keep this open for the time being.
I will look into it a bit more, maybe some driver tweaks can change the behaviour ( Specifically, I miss a left handed / right handed setting or something similar on Gnome 43 ), and I at least want to add this to the "Pitfalls & known issues" section of the README
For reference: This behaviour is a feature in libinput, they call it location-based touch-arbitration. Explained here