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

Keys-press doesn't send Mhub message #18

Open
kmeesters opened this issue Nov 10, 2016 · 4 comments
Open

Keys-press doesn't send Mhub message #18

kmeesters opened this issue Nov 10, 2016 · 4 comments
Labels

Comments

@kmeesters
Copy link
Member

Test case:
Display: http://asia.display.fll-tools.com:1391/
Clock: http://asia.display.fll-tools.com:1392/

Open the control panel of the clock, clicking the buttons also updates the displayserver. However using the keys (keyboard) doesn't affect the display system

@kmeesters kmeesters added the bug label Nov 10, 2016
@rikkertkoppes
Copy link
Member

I'm not sure it should. What is the use case?

@kmeesters
Copy link
Member Author

I'm starting the clock from the clock application. I also have a displaysystem open.
When I use the control panel from the clock by clicking buttons the clock in the displaysystem also starts. But if I use keyboard presses instead of clicking buttons it does not start.

Either we should be clear that you can't start the displaysystem clock from the clock application at all, or support all input methods (mouse + keyboard) but not only the buttons and not the keypresses

@rikkertkoppes
Copy link
Member

My rationale was it doesn't really make sense to use the keyboard in an mhub environment anyway.

I may be wrong though. Having mhub messages sent in any case is a tad more uniform

@kmeesters
Copy link
Member Author

Got it, it might just be confusing for the end user. It was unexpected behavior to me that mouse = mhub messages, but 'same' buttons triggered through the keyboard != mhub messages. (esp since the buttons tell you they keystrokes).

I'd prefer to have them send mhub messages in both cases. But can also see the argument for not doing it (to prevent an accidental start). I'd just suggest uniform behaviour. Just my 2 cents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants