Rnote moves page even when draw with touch input is enabled. about rnote HOT 8 CLOSED

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

from rnote.

0c0e391 and the following bug fix commits should fix this issue!

from rnote.

Bug in action video.zip

Had to compress it because the size went over by a few bytes :P

from rnote.

Or somehow change the propagation phase of the gesture in the ScrolledWindow to the Bubble phase,

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.

from rnote.

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.
Anyways, implementing the scrollable interface is a lot cleaner and should be done anyways at some point in the future. ScrolledWindow's behaviour is to add the child widget directly when it implements the Scrollable interface, and despite the misleading property name "kinetic-scrolling" and its documentation, it would also disable touch-scrolling. (EDIT: maybe, maybe not. that issue is gtk3, so I don't really know if it has changed in gtk4 so I think it would be needed to test it)
But its quite a bit of work, so contributions are more than welcome. :)

from rnote.

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?

From gtk3 manual:

This should be enabled if any child widgets perform non-reversible actions on GtkWidget::button-press-event. If they don’t, and handle additionally handle GtkWidget::grab-broken-event, it might be better to set capture_button_press to FALSE.

If I'm reading this right, we can grab input by grab-broken-events. Right? We should be able to implement custom handling, i.e. just pass values to the virtual ink to draw. So if this is to go by, it might still work with some sneaky workarounds if this still exists.

from rnote.

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.
But there is still some work to be done, because I had to get rid of the overlay (which was responsible for displaying the SelectionModifier widget with the drag and scale nodes) between the ScrolledWindow and the canvas, so now the SelectionModifier needs to be drawn inside the Canvas with a custom layout manager I think.

from rnote.

Disabling kinetic-scrolling does disable touch scrolling! I am working on it.

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!

from rnote.