Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[fix] GestureDetector: add PANINTERVAL #4666
I never witnessed that issue about pan & swipe for menu - mostly because I tap for menu, and i mostly read cre where there is no scroll/pan of content :)
So, I just tested some bit I worked on that deal with pan: MovableContainer, which seems broken after this change. I can witness it with a QuickDictLookup or SkimTo widget. Giving you what I do and how it is supposed to work so you can reproduce it:
1 and 2 are ok after your change. But 3 doesn't move at all.
MovableContainer is tricky, and use intermediate events, and some intermediate states for missing events.
Not sure what's missing (no real time to investigate
Oh, TextEditor supports pan too. And it's also broken. Might be a lot easier to debug :)
Feedback about it has been quite persistent. ;-)
Huh, I had no idea. That's interesting. I'm not really seeing much a difference though. It would seem you have to hold it for a split second at the start and end of your movement with or without this change. However, the timeout increases the initial delay by… 300 ms, I imagine.
I'm afraid I'm not following any of this. :-) I can't spot any difference between v2019.2 and current master or master + this commit.
How about something like this:
if (tv_diff.sec == 0) and (tv_diff.usec < self.PAN_INTERVAL) then pan_ev.relative_delayed.x = tev.x - self.first_tevs[slot].x pan_ev.relative_delayed.y = tev.y - self.first_tevs[slot].y end
And then ReaderPaging/ReaderRolling:
function ReaderPaging:onPan(_, ges) if self.bookmark_flipping_mode then return true elseif self.page_flipping_mode then if self.view.zoom_mode == "page" then self:pageFlipping(self.flipping_page, ges) else -- switch to delayed self.view:PanningStart(-ges.relative.x, -ges.relative.y) end elseif ges.direction == "north" or ges.direction == "south" then self:onPanningRel(self.last_pan_relative_y - ges.relative.y) self.last_pan_relative_y = ges.relative.y end return true end
So that it's like a hidden second type of pan.
Ah, didn't see that we would get:
which let a very small 200ms to get into pan so that may be the reason MovableContainer and TextEditor didn't work as expected.
I was talking about the feature that #4145 introduced (probably better described there :)
I'm not really familiar with this gesture code and workings.
Quickly tested that everything that didn't work with the previous version now works correctly with the latest.
(If I had to have a go at it, I would probably have tried adding a handler for onPan in readermenu, or onSwipe in readerpaging, and put into some first one triggered a
That could make sense. I approached this as a generic pan problem. The ReaderPaging/Rolling workaround idea came much later.
On the flip side, ReaderPaging/Rolling only listens to onPan, which has no concept akin to
referenced this pull request
Feb 27, 2019
MovableContainer and TextEditor do work fine now.
I quickly tested ReaderRolling in scroll mode - and it looks a bit less smooth, or slower -might be that initial delay. But I don't know much about how it should behave.
What I usually do for testing (mostly on Android) is hold and swipe north and south and north while still holding, and it does some kind of continuous scrolling... (bug or feature, I don't know).
Also, after I had reverted 4666.diff, with the above hold-swipe-up-down-up-down-release, when releasing that hold, I get this crash:
So, good if that's what you had been fixing with the TimeVal fix.
Right, that's the intent. Without the delay you get a lot of at best distracting panning going on. There are other ways to avoid that problem that could be investigated (e.g., designate a pan area and a multiswipe area). I'll merge it then. :-)
Definitely a bug I'd say. It might be a feature if it limited itself to half a second or at most a second.