Repository navigation
BUG Run Command (OS) does not work in conjunction with Change State (Deck) #23
Description
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:
- Add a run command to a blank key with command
echo 1 >> ~/testlogand verify that it updates that file - Add a state to the key
- Add a Change State action to the key, which switches to State 2
- Wait several seconds (for some reason the bug does not occur if testing immediately after adding the Change State action)
- Activate key
- 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
Activity
Core447 commentedon Feb 3, 2025
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 commentedon Feb 4, 2025
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 commentedon Feb 7, 2025
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 commentedon Feb 7, 2025
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 commentedon Feb 9, 2025
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 Upetc. Most actions simply trigger onKey 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 commentedon Feb 9, 2025
Core447 commentedon Feb 10, 2025
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.