So I’ve been meaning for a while to write an abstraction for menus to make it easier to write them, make them all behave the same and hopefully use less memory. I’ve started writing implementations a few times, but so far I haven’t written anything that I’m particularly happy with, possibly because I’m trying to solve too many problems at once, so I thought, maybe it’s time to have a discussion about it.
Here’s some of my thinking on the topic so far:
A menu is really a sub-class of something called a “Mode”. A mode would be a class that would take over all interactions temporarily. A mode can have any kind of interactions, buttons, clashes, twists, whatever.
A menu is generally a list of menu entries, and we’ll need four types of interactions, up, down, select and exit. (Although up and down are generally done by twisting right or left on a saber.)
Menu entries can be active, meaning what is shown or played may change depending on settings.
The action taken when a menu entry would generally be a function call of some sort, but there should be an easy way to link it to a sub-menu.
So far it’s fairly non-controversial, but my ideas keeps going. It would be nice if…
menus could integrate with displays, or other output devices, ideally without the prop needing to do a bunch of extra stuff to make that work.
Menus should be extensible so that we could have a base settings menu that implement settings that exists in base_prop.h, then extend it with settings that are unique to each prop without having to duplicate the settings that are in the base prop.
The left/right/select/exit actions should ideally be controlled by the prop, not the menu. Maybe someone wants to wave the blade to go up/down instead of using twist motions? However, this gets a little weird, because not all menus might require exactly those actions (like for instance a color wheel menu) .
And then there is the really weird stuff…
The PQOI format is powerful enough to possibly implement entire menu systems in PQOI files. We’d need two things: 1) a way to send events to the screen so that the they can be picked up by conditional gotos in the file. 2) a new PQOI entry that allows sending events back from the display to the prop once a selection is made. All of this would be pretty cool, but I don’t really see a way to make it work with the prop menus, and do we really want two menu systems?
With the disclaimer I need to reread and fully absorb what you’re saying here what about maybe a basic and an elite menu set choice? Is that doable without creating a bigger headache overall?
Know what I mean? Like how Fett263 has EditMode and then EditSettings or even more basic and no use of either and it’s bare bones?
Happy to help where I can, where would the actual “actions” and values of the menus reside? The main structure of the Edit Mode mode was fairly straightforward but the actual functions where things “happened” varied considerably and in many cases the options in the menu depended on the current active blade/style.
In some cases, the supporting functions for the menu were tied to other things specific to my prop which made them hard to move when we were first looking at sharing with other props.
This thread really isn’t about making a menu, or even a set of menues, but making a framework for making menus. This should make it easier for other props to implement menues, and I may even add some menus to the basic saber prop, but if I do, it will certainly be optional…
Everything you said under your current “thinking on the topic so far” makes perfect sense.
Integrating with displays sounds like an excellent option. Maybe make it so that each menu entry can have an optional bmp name associated with it? I’m completely unfamiliar with the ProffieOS source code, so forgive any blissful ignorance, but something like in the instantiation of the mode (menu), there is a given bmp name specified, and then the standard 001, 002 naming convention would apply when searching for files with that name, and the associated bmp/bmp animation would play. Function calls inside the mode could maybe temporarily change the bmp, but it would always have one associated with it at its core.
Makes sense to have the basics set up already, but definitely make this a define and not the default, don’t want to have too much for the user to interact with and accidentally get lost in if they haven’t enabled it.
It also I think would be worth making sure that the default menus are maybe virtual and can be overridden by a prop file, particularly for the purpose of wanting to change what button combo activates it to not conflict with other prop buttons. (Though maybe there’s merit in trying to standardize this?)
The actions for the menu should definitely be, at the very least, something that has multiple options. So given the example scenario, maybe a default “selection” navigation system where there’s that left/right/select/exit, but then another for “wheel” nagivation, where there’s the color wheel style implementation and then select/exit, and so on for each type of interaction, and maybe props could create their own navigation systems and then use them for their modes?
I dunno anything about PQOI… I’ve only looked at it in brief
An excellent question. I don’t have all the answers yet, but I’m thinking that each menu should be it’s own class, which means that the save/restore/change/select actions all go in that class. One of the major benefit of doing this would be that all the code that belongs to one menu ends up together, rather than spread out.
I’m also thinking that there would be some abstraction for finding menues of a given type. One possible way to do this would be to have an enum of standard menu types, and then have a function somewhere like:
Menu* getMenu(MenuType t);
The idea here is that it should be easy to make modifications to a single menu without having to re-build the whole menu system.
Of course where this gets a little more interesting is when the menues go dynamic, it’s not entirely clear how to model “find the font selection menu for preset 14”.
