-
Notifications
You must be signed in to change notification settings - Fork 1
Create Menu System #80
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
Conversation
Previously I was detecting items in the demo queue. I changed it to detect SEL or SEC in the system queue. This made the logic way eaiser.
isort and black are disagreeing and I don't have the time to figure out why.
christopolise
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks great wholesale, however I am having issues with the Enter key actually working with my simulator (both in the standalone of the menu demo and also in the full simulator mode). Is anyone else (@apal6981) experiencing this?
|
That might make sense. Right now, the code is capturing the |
Now it will be just SEL.
christopolise
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the direction this is going. I am not sure whether or not the queues are functional in the sense that they actually start the demo. I checked to see why hitting Enter didn't launch the new demo and it turns out that the code is picking up the keystroke, but hitting Enter doesn't actually launch the demo. This happens when running in demo mode (i.e. python main.py demo menu -s or python main.py simulator
|
Yes, you are correct. That is by design. The only time the menu system will work is in kiosk mode. It takes care of checking the key presses and launching the menu demo. I apologize for not making that more clear. |
|
This PR is waiting for @apal6981 approval and to be tested on hardware before it is accepted. |
apal6981
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything looks good, but lets run it on the hardware before we approve ;)
I think I developed a good solution to show the user a menu to pick a demo. Here is how it works:
Now, on to how I implemented it:
I created a new demo called menu. This menu demo is pretty much a regular demo, except it takes one extra argument that all other demos don't have: a reference to the input system queue.
In the kiosk runner, if someone presses select, the current demo quits, and the menu demo gets called. That logic is handled in the kiosk runner code.
When someone selects a menu item, the menu demo puts the name of the selected demo in the system queue. This is similar to how the web MQTT controller worked. It is quite elegant because it reuses the machinery that is already built into the SSS. However, it requires passing the input system queue into the demo, which is not ideal.
For this system to work, I had to change how select button presses are published. Previously, they were published on the demo queue. I propose in this PR that we publish it to the system queue. Essentially, we are giving the system access to one button that a demo won't have access to. I also removed the release event for the select button since a demo is not using it, and it is a pain to have to handle two events.
I also fixed a few bugs:
More work could be done on making the menu demo better, but I think for now it is a good start.
Will you try it and give me some feedback? It is on the menu_system branch.
This fixes #70.