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

EVENT_TYPE_MENU_UPDATEs not destroyed when a menu is opened #8

Open
mebibytedraco opened this issue Jul 14, 2023 · 3 comments
Open

Comments

@mebibytedraco
Copy link
Contributor

EVENT_TYPE_MENU_UPDATEs add themselves back to the event queue as long as the menu is open; if I'm understanding the code correctly, the only time they are removed from the queue is if a menu item is clicked, or if the menu overlay is disabled when the event handler is called, and there should really only be one in the queue at a time. If a menu is open, and another menu update event is added to the queue by clicking on an item in the menu bar, the first menu update event is not removed. Repeatedly clicking the same item on the menu bar will add more and more events to the queue, which will lag the system until the menu is closed and the events are removed.
I actually first ran into this issue when trying to open a menu when a different menu was already open. Since both events are in the queue, both of them attempt to update the menu whenever the mouse is over them, leading to a weird effect where the menu sort of runs away from the cursor.

event_type_menu_update_issue_2.mp4
@ry755
Copy link
Contributor

ry755 commented Jul 14, 2023

It's been a really long time since I last worked on menu stuff (the menu bar was the first UI element I ever implemented for fox32rom/os), so tbh my memory of how it all works isn't very good :p
When an event is fetched from the queue it is automatically removed from the queue, which is why menu_update_event re-adds them to the queue as long as the menu remains open. This results in menu_update_event continuously being called while the menu is open, which handles redrawing and detecting menu clicks. Unless I'm misunderstanding what you mean, this is intended (though whether it's actually a good system or not is debatable).
I think the main bugs here are the fact that clicking on the same menu bar item a bunch of times slows down the system, and that clicking on a different menu bar item while a menu is already open causes that effect where the menu runs away from the cursor. Also while I'm at it, implementing the ability to close the menu by clicking anywhere outside of the menu would be nice, rather than needing to click an empty space in the menu bar.

@mebibytedraco
Copy link
Contributor Author

Thanks for confirming that this is the way the menu system works. Is it supposed to be possible for there to be more than one event of type EVENT_TYPE_MENU_UPDATE in the queue at once, or is this unintended?

@ry755
Copy link
Contributor

ry755 commented Jul 15, 2023

That is unintended.

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

No branches or pull requests

2 participants