Action chains
spyoungtech opened this issue · 6 comments
Something like selenium's ActionChains
.
Not sure if this is useful for people, so speak up if you like this.
I think for a lot of reasons, reworking ActionChains to produce a single script will be useful. It will make #30 easy, but I think more importantly, it would be a good way to define actions for hotkeys. In other words, maybe rather than doing .perform()
on the action chain, you can turn it into a hotkey. Maybe:
ac = ActionChain()
ac.mouse_move(100, 100)
ac.sleep(1)
ac.click()
ac.mouse_move(200,200)
hotkey = Hotkey.from_action_chain('^r', ac)
ActionChains are likely going to be deprecated and removed in a future release.
One vote for ActionChain. Checking it out for Windows test automation. At the moment, conditional execution branches are a little tricky, but on the other hand, calling run_script via subcommand (e.g. with ahk.AHK()) is just too slow for convenience.
Thanks for that feedback @d3rp
The way I'm seeing things right now is that action chains aren't providing any value over, say, just writing a small function to perform a set of actions. And, like you say, they don't provide for conditional execution.
Originally, I think there was a vision where the action chain would combine into a single script for performance improvements on rapidly repeated actions. For example, clicking or moving the mouse hundreds of times per second. Today, the subprocess execution time limits the interval at which actions can be taken so you may only be able to click so many times in a second.
Though #111 may help overcome the performance limitations that exist today.
So the daemon mode would work like the basic AHK object running commands one by one, but instead of triggering them via subcommand - and thus waiting for the overhead of spawning a process - have them executed by a daemon? And this would result in similar performance as the ActionChain?
If so, it sounds like a more plausible option than ActionChain. AC is kind of tricky to handle, as besides the conditionals one can't really dive in to the runtime in other means either - for example for logging. In other words, user created logging would basically describe what commands are being appended to the chain instead of what is being executed while running.
This could be handled probably with some kind of a "functional" approach and a tree for branching, but considering there's already two layers of languages for abstraction, that sounds a little heavy for most projects. The stateful approach of the daemon is probably much easier to use in practice.
Action chains are removed in v1