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

Menu item generators #4

Closed
pgaskin opened this issue May 2, 2020 · 2 comments · Fixed by #28
Closed

Menu item generators #4

pgaskin opened this issue May 2, 2020 · 2 comments · Fixed by #28
Assignees
Labels
Milestone

Comments

@pgaskin
Copy link
Owner

pgaskin commented May 2, 2020

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

@pgaskin pgaskin added this to the v0.1.0 milestone May 2, 2020
@pgaskin pgaskin mentioned this issue May 7, 2020
@pgaskin
Copy link
Owner Author

pgaskin commented May 11, 2020

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 pgaskin self-assigned this May 13, 2020
@pgaskin
Copy link
Owner Author

pgaskin commented May 24, 2020

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).

This was referenced May 24, 2020
pgaskin added a commit that referenced this issue May 25, 2020
* Implemented menu item generators (closes #4)
* Initialized sz to -1 for nm_generator_do
* Cleaned up extra semicolon in config.c
* Fixed typo in generator size check
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant