Closed claytono closed 5 years ago
Hey, @claytono, I don't understand the whole reverse=True
thing. Where is it being used? If we're using two different locations in the yaml, one for scrolling down and another up, it seems kinda pointless?
Also, check my comment on incoming line 131: at first glance, that looks like a "tap&hold" feature that's simulated via a swipe using the same coordinates for 'start' and 'end'. Does this PR requires that functionality in order to work? In case it doesn't I'd say it should get it's own PR rather than sneakily getting though this one. Do you guys agree?
@esauvisky I originally had it using the same coords for both scrolling up and down, and the reverse arg is left over from that. I'll clean that up and make the swipe duration configurable also.
I didn't understand what that block was trying to do. Tap and hold makes sense. I'll make that a separate method.
I've updated this to only scroll down if calcyiv isn't reporting the fast and charge moves already. This also fixes the regex used for parsing the special move, since calcyiv is sending both the first and second charge move.
Why did you close the PR? Well, I merged it on my fork anyway :grin:
This adds a new
get_moves
action which will scroll down to the moves part of the screen using a swipe input, trigger calcyiv, and then scroll back up to the top. The scroll up swipe is slightly longer than the scroll down, because I found that it didn't always scroll completely to the top otherwise.Note that the config.yaml.example coordinates are for a pocophone and probably don't work on a 1080p phone.