Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

device = "sleep" on action_hold doesn't work properly #79

Open
henryso opened this issue Feb 8, 2022 · 5 comments
Open

device = "sleep" on action_hold doesn't work properly #79

henryso opened this issue Feb 8, 2022 · 5 comments
Labels
bug Something isn't working

Comments

@henryso
Copy link
Contributor

henryso commented Feb 8, 2022

When placing the device = "sleep" action on the action_hold of a key, it doesn't work as it should. The device will "wake up" as soon as the key is released. I tried modifying github.com/muesli/streamdeck to ignore "wake-up" events that all button release, but this doesn't quite fix the problem. Deckmaster still thinks the button is still held down because it was never aware that the device went to sleep.

There are three solutions that come to my mind.

  1. Allow a channel to be passed to streamdeck.Device to receive events such as this so that (in this case) Deckmaster can clear its keystate tracking. Incidentally, adding such a channel may help with the "clear the deck" and "show it again" sleep-related feature that I'm looking for.
  2. Send key release events for all pressed keys when the device sleeps. This way, it will appear to Deckmaster that all keys are released when the device sleeps and will track that "normally".
  3. Take the key-hold event generation into the streamdeck library somehow. This way, Deckmaster will receive key press and key long-hold events separately and doesn't need to track key timings. However, this makes the streamdeck library more high-level (so perhaps it should be optional somehow).

Which do you prefer, or do you prefer something else?

@muesli muesli added the bug Something isn't working label Feb 9, 2022
@muesli
Copy link
Owner

muesli commented Feb 9, 2022

Another option would be not triggering the action_hold until the key has actually been released. This is probably more consistent behavior. I'll push a PR you can play with, to see how it feels.

@henryso
Copy link
Contributor Author

henryso commented Feb 9, 2022

I don't know if it's better to continue the discussion here or in the PR, so I'll go with here unless you tell me otherwise.

This changes the behavior of the application, which some users may not like. As for me, I think this a workable solution, but needs to provide some feedback to indicate when the button has been pressed long enough. With the old behavior, the firing of the action was itself that feedback, but now the user doesn't quite know if they have held the button long enough to fire the hold action and might accidentally fire the non-hold action when releasing the button.

@henryso
Copy link
Contributor Author

henryso commented Feb 10, 2022

Would you be amenable to extending the Widget interface to allow Deckmaster to ask widgets to indicate a long press?

@muesli
Copy link
Owner

muesli commented Feb 13, 2022

I know and I personally also prefer the immediate feedback of the previous solution. I'm still pondering how to solve this differently.

Would you be amenable to extending the Widget interface to allow Deckmaster to ask widgets to indicate a long press?

Can you elaborate a bit what you have in mind? 😃

@henryso
Copy link
Contributor Author

henryso commented Feb 13, 2022

Can you elaborate a bit what you have in mind?

The idea (of course only necessary if the trigger is the release) is that the button widget could be asked to provide feedback.
For example, it might invert the colors of the button to indicate that the button will fire the long press action when released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants