search

pgaskin / NickelMenu

The easiest way to launch scripts, change settings, and run actions on Kobo e-readers.
https://pgaskin.net/NickelMenu
MIT License
591 stars 32 forks source link

Menu item generators #4

Closed pgaskin closed 4 years ago

pgaskin commented 4 years ago

Continued from the discussion in geek1011/kobo-plugin-experiments#2.

pgaskin commented 4 years ago

I've decided that the most likely approach I'll take to this is an additional config entry type (as opposed to restructuring the entire config). It'll look like menu_items:<source>:<args>, and will be parsed, executed, and added separately. During the config parsing it will be mapped to a nm_menu_item_generator_t, which has a function pointer and a string for the args. After the parsing is complete, it will be executed with a pointer back to a field of nm_menu_item_generator_t for the parsed items. This will likely be done async from another thread. Then, during item injection, the items will be added from that field if they are ready at that time.

pgaskin commented 4 years ago

To simplify things, I'll keep the generator stuff in the config file parser, and have another function (which will be called after the config file is parsed) which expands them (to more config entries/menu items or to an error menu item) recursively (if we expand to config entries -- this is easy to implement because we use linked lists; we just need to change the pointer to the next item to point to the first generated one). If we end up needing async stuff or retries later, I'll refactor the config parser into something more suitable.

I haven't decided if I'll have it generate menu items (for a specific location), or generic config entries (and it'll be up to the generator to handle the location, but it'll be more extensible in the future). I'm slightly leaning towards the first option, as I'd rather refactor the config parser (mainly the parts which allocate/append the objects) before doing anymore major changes (it's been getting somewhat messy). On the other hand, the second option would allow us to reuse most of the linked list stuff from the config (but it would mean that nm_config_t would need to be made visible to the other files).