BUG Run Command (OS) does not work in conjunction with Change State (Deck)

[gardener2]

Describe the bug
Run Command actions do not execute if there is also a Change State in the actions for the key

To Reproduce
Steps to reproduce the behavior:

1. Add a run command to a blank key with command echo 1 >> ~/testlog and verify that it updates that file
2. Add a state to the key
3. Add a Change State action to the key, which switches to State 2
4. Wait several seconds (for some reason the bug does not occur if testing immediately after adding the Change State action)
5. Activate key
6. Note that nothing was appended to the testlog file

Expected behavior
A 1 should be added to testlog regardless of the presence of a Change State action

Screenshots

[Core447]

The problem with the normal "Run command" action occurs, because it's waiting for the key to get released, but the action will never receive this signal as it gets send to State 2. Using the "Easy Run Command" action should avoid this.

[gardener2]

I can confirm that using Easy Run works, but it's still pretty unintuitive/confusing, I spent a while trying to figure out what was wrong with my scripts before noticing that the Run Command doesn't work as expected in this circumstance

[Core447]

I can confirm that using Easy Run works, but it's still pretty unintuitive/confusing, I spent a while trying to figure out what was wrong with my scripts before noticing that the Run Command doesn't work as expected in this circumstance

I completely understand this. The only way I see to improve this situation would be to rename the "Easy Hotkey" into "Hotkey" and "Hotkey" into "Advanced Hotkey". Do you maybe have a suggestion?

[gardener2]

To me it seems like the ideal functionality would be either that all actions are executed before a state change, or still executed afterwards despite the state change. If that isn't possible and a state change necessarily prevents another action from executing at all, then maybe the next best functionality would be that the interface prevents you from adding two incompatible actions to the same key (they aren't going to work together anyway) and gives some kind of message indicating where the conflict is.

With just renaming Run Command and Easy Run Command, there would still be the possibility of a confusing situation, but I do think that would be helpful and that if they were named that way I would have likely ended up choosing the one with the shorter name and not personally run into this problem.

[Core447]

and a state change necessarily prevents another action from executing at all

The issue you encountered only occurs with a small set of actions because of how they react to events. In StreamController actions get different events for Key Up, Key Down, Key Hold Start, Key Short Up etc. Most actions simply trigger on Key Down, but because the "Hotkey" action has options to repeat the keypress while being hold it only executes when it receives one of the "up" events.
When you have a change state actions before it, and press the button, both actions will receive the "Key Down" event which will cause the "Change state" action to change the state, but the "Hotkey" action, while receiving the event, doesn't do anything, because it waits for an "up" event.

And that's also why the "Easy Run Command" works: It only listens to "Key Down", because it doesn't have said hold options and will therefore trigger as expected.

What I want to say with this is that this is basically a problem of the "Hotkey" action and therefore the app itself can't do much to prevent this. The only way we could prevent it, would be to keep track of state changes and what the previous state was and then send all the "up" events to that state as well. But this adds complexity that is unnecessary in most cases and will probably cause more unexpected behavior than it solves.

That's why I think the best solution is probably the renaming of the actions.

[gardener2]

Makes sense, though I still think some kind of interface guardrails would be appropriate here, since all this functionality with key events is abstracted from the user, and a name change wouldn't by itself convey understanding of what will and won't work or why.

[Core447]

Ok, yeah, I'll see what I can implement without changing too much of the current system. But this may take a while, as it's not a priority for me right now.