-
-
Notifications
You must be signed in to change notification settings - Fork 212
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
Rnote moves page even when draw with touch input is enabled. #22
Comments
Had to compress it because the size went over by a few bytes :P |
Thanks. This is because the ScrolledWindow captures the touch input before the custom drawing widget ( the Canvas). The solution would be to reimplement the drag gesture and connect it to the Canvas widget , then disabling it in the ScrolledWindow. Or somehow change the propagation phase of the gesture in the ScrolledWindow to the Bubble phase, therefore coming after the input is already captured by the Canvas when touch input is enabled. I think the first solution is preferable, but also requires deriving and implementing the Scrollable interface for the canvas |
This might not work without significant modification to ScrolledWindow maybe. But the first for the first option that would require reading input BEFORE Gtk ScrolledWindow is passed those values. Im not that familiar with that widget but is there a way to lock it so that it ignores any input? That might be preferable and then the canvas can just interpret touch inputs. |
I believe so too with the ScrolledWindow, I briefly looked into it but the only way I have found to access is maybe through the observe_controllers() method which has a huge disclaimer that applications should avoid it. |
Yeah but the immediate next comment just flat out says it wouldn't work. Sad considering that its more or less what we would be looking for. Carlos did say setting capture_button_press to false might work but that depends on if the API works as intended and the discussion seems to indicate this is no longer the behaviour. And it seems gone in gtk4 too, I didnt find it listed on gtk4 reference. I may also aloof and miss things at times, but I did not find anything that resembles this in gtkscrolledwindow.c so it seems it was dropped unless it is actually kinetic scrolling we are looking for. It seems kinetic now actually refers to the kinetic behaviour and not scrolling as a whole. So no way to disable scrolling :( Yeah, in this case we can have a "stub" widget to capture events for us before scrolledwindow gets it and disable propagation (depending on current option). Here we can pass it directly to canvas, assuming it also contains positions relative to something. Not sure about how Canvas knows the position. Dont really like this due to the slowdown comment there. Maybe we should raise an issue with Gtk to add that feature back? Completely disable scrolling while allowing propagation?
|
Disabling kinetic-scrolling does disable touch scrolling! I am working on it. The custom touch drag gesture will be on the ScrolledWindow, and will have the Bubble propagation phase. The behaviour will be: If touch drawing is disabled, you can touch-scroll anywhere on the ScrolledWindow. If touch drawing is enabled, you can touch-draw inside the sheet area, but still touch scroll on the sides beyond the sheet borders. I think this is the best behaviour we could have. |
HAHA!!! If it does that, the naming scheme is indeed broken! 😃 I was digging in considering they would use the right name deep down. Cause even the comments in the code kinda feel like they're referring to kinetic scroll! |
0c0e391 and the following bug fix commits should fix this issue! |
Using flatpak version of the app 0.1.6, the app still moves the page when interacting with touchscreen even when draw with touch input is enabled.
The text was updated successfully, but these errors were encountered: