Closed adamsoutar closed 1 year ago
I feel we need to figure out a safe mechanism to put in place of the unsafe callback before adding this.
Does the SKD doc say anything about when this callback will be called, relative to the other callbacks Crankstart is already handling?
Hmm, I think you're right. Initially I couldn't figure out a way to pass in a Rust function with any useful context since closures etc. can't be passed as simple function pointers. However, this SO question seems to provide some ways to do it - I'll look into it.
In terms of timing, the docs say that pressing a menu item
eventHandler()
with kEventResume
in that order
As long as we are reasonably certain that none of the other callbacks ever get called while the menu is open, we could handle it the way we handle the other callbacks and perhaps add a method to the Game trait.
Reading the system menu docs I think that there are two ways to go; either make menu items like sprites or design an API for Rust that doesn't require an immediate callback per item and keep all the references to menu items internal to Crankstart.
Closing this as it is quite old. Please feel free to re-open.
I'd really like to have system menu access for my game. @rtsuk would you mind if I create an issue to track this, and try to summarize the issues under consideration above?
Go for it!
👋 This PR adds bindings for interacting with the System Menu.
For example:
It also supports "checkmark" and "options" menu items:
Totally open to feedback/thoughts on this one since it's a bit bigger than my previous PRs and involves a bit of API design 🙂