Replies: 1 comment 1 reply
-
I think you are hitting the problem that the actions don't wait for the previous one to complete before executing the next. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm trying to understand if what I'm trying to do is a bug or whether there is some other way to do it. I'm wanting do do the following:
Action 1 and 3 work just fine, but I'm not getting action 2 to abort executing action 3. It always outputs the text to the current window. If the target window is actually open, it is changing focus to it and sending the text or keys to it. But I'd like to also have a failsafe that it only does so if the window is found open.
I ended up with the action 'internal: Actions: Abort delayed actions on a button' as being the most likely one to try for Action 2 above. I could have opted for some form of Trigger, but it would mean more scheduled triggers running in the background which is messy.
So I have the action as it appears below here, and I set it to expression, and in the expression I put
$variable=='false'
but it is not aborting the queued Action 3. I have small delays set between the actions to allow them to fire one after each other.So what I'm trying to find out is:
Note: I should just add this is on Linux, and when I'm in the X11 desktop of course this is not needed as xdotool will direct a key press or typed text straight at a named window all in one command. I'm trying to get this to work with Wayland, so I have to use the ydotool command, and that command cannot do such direction into a named window. The only way is to change focus to the window, and then output the keys as a second action step.
Beta Was this translation helpful? Give feedback.
All reactions