Would be cool if menu items can be defined without explicitly naming ids and the parent element "path".
Currently, menu items are generated by a macro system that emits setup code, thereby creating a linked list of items.
This macro system is quite fragile if the menu needs to be edited. Eg. it is not possible to remove a single entry without updating all consecutive ids etc.
Maybe we could to move to a static definition of nested arrays?
These could be created in legacy compatible fashion by the existing macro calls.
or they could be defined by new macros omitting the id and path parameters - those can be more easily edited, eg copy / paste or put under #ifdef conditions without braking the id numbering
Or they could be created by direct initalization in vanilla C (structs with nested array initalizers)
A single setup function can then recurse the tree and set up the id and parent, sibling and children pointers
-Theoretically at some day the sibling pointers could be removed, as siblings are consecutively stored ( a "end marker" element would be needed then)
Would be cool if menu items can be defined without explicitly naming ids and the parent element "path".
Currently, menu items are generated by a macro system that emits setup code, thereby creating a linked list of items. This macro system is quite fragile if the menu needs to be edited. Eg. it is not possible to remove a single entry without updating all consecutive ids etc.
Maybe we could to move to a static definition of nested arrays?