-
-
Notifications
You must be signed in to change notification settings - Fork 395
feat: Option to disable touch scrolling #1385
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
base: main
Are you sure you want to change the base?
Conversation
For the first point, maybe check https://wiki.gnome.org/HowDoI(2f)CreateSymbolicIconsThatChangeColorAccordingToTheme.html (it's for gtk3 but I think it should suffice). I think that's the absence of fill color that play a role in the theme working. I'm not sure I understand the second point. Can you explain in more detail ? |
That was my understanding as well. But it didn't look good without the gray part. It seems to be possible to have some styling because some icons do it anyway... I'll look at the gnome documentation you linked because it seems to hold the answer I'm looking for.
From what I understand, around here I'm "blocking" all events linked to drag motions. But apparently if it comes from the intertial/kinetic scrolling, it goes somewhere else (I'm not sure where). In practice this means that gtk still recognize the touch input and generate inertial scrolling for them which is then not ignored. |
c0a7f5f
to
4e260c2
Compare
A month later, I finally had time to work on this again ^^' As far as I can tell, all the problems I listed above are fixed. I ended up changing the icon to another one straight from the gtk repository because I couldn't make it follow the theme... |
Could this maybe be looked at again? It would be practical to have this feature. |
Well, I far as I can tell, my branch works (I've been using it since my last comment, and it hasn't crashed on me). I need to rebase anyway because this is the version of |
just so you know everything has been rebased and is apparently working. |
self.touch_long_press_gesture | ||
.set_propagation_phase(PropagationPhase::Capture); | ||
} else { | ||
// set everythinbg to `None` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo
#[weak(rename_to=canvaswrapper)] | ||
obj, | ||
move |_, _, _| { | ||
if canvaswrapper.block_touch() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does the canvas drag gesture activate even with the propagation phase set to none ? or is it to stop a gesture in progress when clicking on the button ?
I think the latter could be done with https://gtk-rs.org/gtk4-rs/stable/latest/docs/gtk4/prelude/trait.GestureExt.html#method.set_state (EventSequenceState::Denied)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a bit unsure, I was following what block_pinch_zoom
was doing, but it does not appear here. So maybe.
I would have to test again make sure, but I won't get access to my touch screen device for 3 more weeks...
This is a merge request closing #1246
This adds a small button to quickly activate/deactivate the touch scrolling on the canvas. For many situations, this is a very good workaround to inconsistent palm rejection.
Remaining to do:
Outside those two points, it has been working flawlessly on my (admittedly outdated) fork for the last 6 months.