{"action":"created","issue":{"url":"https://api.github.com/repos/littlevgl/lvgl/issues/557","repository_url":"https://api.github.com/repos/littlevgl/lvgl","labels_url":"https://api.github.com/repos/littlevgl/lvgl/issues/557/labels{/name}","comments_url":"https://api.github.com/repos/littlevgl/lvgl/issues/557/comments","events_url":"https://api.github.com/repos/littlevgl/lvgl/issues/557/events","html_url":"https://github.com/littlevgl/lvgl/issues/557","id":381759757,"node_id":"MDU6SXNzdWUzODE3NTk3NTc=","number":557,"title":"Feature suggestion: Micropython binding","user":{"login":"amirgon","id":11742638,"node_id":"MDQ6VXNlcjExNzQyNjM4","avatar_url":"https://avatars2.githubusercontent.com/u/11742638?v=4","gravatar_id":"","url":"https://api.github.com/users/amirgon","html_url":"https://github.com/amirgon","followers_url":"https://api.github.com/users/amirgon/followers","following_url":"https://api.github.com/users/amirgon/following{/other_user}","gists_url":"https://api.github.com/users/amirgon/gists{/gist_id}","starred_url":"https://api.github.com/users/amirgon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/amirgon/subscriptions","organizations_url":"https://api.github.com/users/amirgon/orgs","repos_url":"https://api.github.com/users/amirgon/repos","events_url":"https://api.github.com/users/amirgon/events{/privacy}","received_events_url":"https://api.github.com/users/amirgon/received_events","type":"User","site_admin":false},"labels":[{"id":389374647,"node_id":"MDU6TGFiZWwzODkzNzQ2NDc=","url":"https://api.github.com/repos/littlevgl/lvgl/labels/enhancement","name":"enhancement","color":"84b6eb","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":89,"created_at":"2018-11-16T21:06:19Z","updated_at":"2018-12-28T23:41:54Z","closed_at":null,"author_association":"NONE","body":"[Micropython](https://github.com/micropython/micropython) is becoming mainstream on IOT and embedded development in general. It is available for quite a few of embedded architectures ([this](https://github.com/micropython/micropython/wiki/Boards-Summary) and [this](https://forum.micropython.org/viewforum.php?f=10), partial list), and can be ported to new ones.\r\nToday there already exist several architecture-specific micropython display modules (for example [this](http://docs.micropython.org/en/latest/library/lcd160cr.html) and [this](https://github.com/loboris/MicroPython_ESP32_psRAM_LoBo/wiki/display)), but none of them as feature rich and general as littlevgl.  \r\nI think it could be useful to provide micropython API to littlevgl Objects and Styles.  \r\nMain benefits are:\r\n- Exposure to a larger audience in the embedded development world.\r\n- Interactive developement. Use the Micropython interpreter to exercise littlevgl over a live embedded board. This would allow rapid GUI development without the build-flash cycle.\r\n- Some would argue Python code is easier to develop and maintain (not sure I agree about this one...)\r\n\r\nIf it turns out there is an agreement about this feature, I might try sending PR if I find the time for it."},"comment":{"url":"https://api.github.com/repos/littlevgl/lvgl/issues/comments/450443924","html_url":"https://github.com/littlevgl/lvgl/issues/557#issuecomment-450443924","issue_url":"https://api.github.com/repos/littlevgl/lvgl/issues/557","id":450443924,"node_id":"MDEyOklzc3VlQ29tbWVudDQ1MDQ0MzkyNA==","user":{"login":"amirgon","id":11742638,"node_id":"MDQ6VXNlcjExNzQyNjM4","avatar_url":"https://avatars2.githubusercontent.com/u/11742638?v=4","gravatar_id":"","url":"https://api.github.com/users/amirgon","html_url":"https://github.com/amirgon","followers_url":"https://api.github.com/users/amirgon/followers","following_url":"https://api.github.com/users/amirgon/following{/other_user}","gists_url":"https://api.github.com/users/amirgon/gists{/gist_id}","starred_url":"https://api.github.com/users/amirgon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/amirgon/subscriptions","organizations_url":"https://api.github.com/users/amirgon/orgs","repos_url":"https://api.github.com/users/amirgon/repos","events_url":"https://api.github.com/users/amirgon/events{/privacy}","received_events_url":"https://api.github.com/users/amirgon/received_events","type":"User","site_admin":false},"created_at":"2018-12-28T23:41:54Z","updated_at":"2018-12-28T23:41:54Z","author_association":"NONE","body":"@rreilink it shows that you made some effort, I appreciate it.  \r\nOn my side I'm still working and changing `gen_mpy.py` script, specifically, adding missing features such as structs and styles.  \r\n\r\nWhen writing `gen_mpy.py`, as a general guideline, I tried to keep my code as generic as possible: I don't care what a function or an object is doing, I just expose it **syntactically** to the Micropython user.  \r\nWhen running `gen_mpy.py` the user can configure the result by changing `#define`s on lv_conf and by providing input to the script (the `-X` option). But in the script itself, I tried hard **to avoid** references to lvgl specific types functions and objects.  \r\nEven for Style and Font, I'm making an effort to treat them as just another (more complex) struct and not handle them explicitly in the code.   \r\nThe reason is that API tends to change and evolve, and changing the python script is harder than changing the inputs for it. It would make the script more \"adaptable\" to changes and additions.  \r\n\r\n@rreilink, what is your opinion about this? I noticed that your code makes more assumptions. For example, `lv_coord_t` `lv_color_t` and `lv_opa_t` appear explicitly as types, and you have an explicit Style object so you are probably treating it different than a generic struct.\r\n\r\n---\r\n\r\nAbout your questions:  \r\n\r\n(1), (2), (3), (8) - In general I prefer hierarchy whenever it's possible, that is the reason for the nested access to enums.  \r\nFrom the user perspective, clicking `TAB` (or `help`) and getting gazillion functions/globals/enums is less favorable than getting a shorter list of only the \"top-level\" ones and drilling down as necessary.\r\nI'm also working on nested access to structs, even when the structs are nested in C. For example `style.body.border.color`. I'm not a big fan of \"getters/setters\" and prefer the more Pythonic \"Attribute\" access (so you could refer to a field in a struct more naturally, as you would in C for a struct field).\r\n\r\n(4) I think we should consider solving inconsistencies by fixing lvgl itself. Looking forward, lvgl does not promise backward compatibility across major releases (see for example #316 where `V6.0` would include a breaking change related to action handlers). Especially when this is a simple naming convention error.\r\n\r\n(5), (9) As I mentioned, I tried not to care what is the purpose of the function. As long as it is defined in an H file that is given as an input to the script, it can probably be useful to the user. Even memory handling and file access functions. If the user would like to remove them, this can be done either by configuring lvgl not to preprocess them, or by some runtime flags to the script.  \r\nThe downside of not knowing the function purpose is that it's harder to handle some cases in a more natural (or \"pythonic\") way (like your example of `get_children`, which returns a list). A solution for that could be defining and implementing some naming convention to describe iterators (and changing lvgl sources) such that the script could deduce the fact that this is an iterator automatically without knowing anything about the purpose of the function. The advantage would be that when a new iterator is added to lvgl it would be automatically supported.\r\n\r\n(6) I think that H files should be sufficient for creating the binding. We only care about API, not implementation. The user provides the API H file to the script and the script generates the binding for that API.\r\n\r\n(7) Ideally I would like to be able to generate \"everything\", the complete Python API for the given set of H files. Practically I'm working incrementally so some functions won't be generated (usually because of missing conversions, but possibly because of conventions or ambiguity issues). From the user perspective when a function is missing, the (power-) user would browse the C sources and try to understand what went wrong. A comment there (\"we wanted to create that function and didn't do that because ____\") is very useful.  \r\nI don't think the script should stop with an error when not able to generate something. It would make it less resistant to changes in lvgl. A small change in lvgl may cause some function not to be available. But the Python binding can still be useful even if it doesn't include everything.\r\n\r\n"}}
{"actor":{"display_login":"amirgon"}}