-
Notifications
You must be signed in to change notification settings - Fork 7
Introduce standardized, parsable comments to facilitate automatic binding and metadata #3
Comments
It was already discussed with @rreilink to aid the Python binding generation with naming conventions. The main issue was that Python bindings (including Micropython) use the C pre-processed code where defines and comments are already not available. So to get the comments the source code needs to be processed. Parsing the comment seems doable if they are added correctly, however, it will make the maintenance more difficult. Let's collect what we need to see what we can do:
|
It may make maintenance of the code more difficult, but I think overall it will be less work. This way, all the information about the code is contained in the code itself. The same reason doxygen is so prevalent. Writing the same documentation twice is more difficult, and maintaining code comments and documentation is twice as much confusion 😉
From my poking around in the python binding, object members that decompose to a primitive just appear to python as that primitive. For example, Perhaps we can just use the variable names to differentiate types like this. So anything ending with
Yes, that's what I'm thinking we should do.
This should be fairly simple. For things like enums or structures we could tag things with
Do you mean something that's non-static? Like a temporary string pointer in RAM that is passed to lvgl when setting the text on something?
... still thinking about this. |
Oh, I really missed that. Anyway, the pre/postfixes should work.
I mean for example in char buf[32] = {"some text"};
lv_label_set_text(label, buf);
return; // buf is destroyed However, for example Some updates should be done in this regard to make it clearer. |
However, it is detected as an |
Can you show an example about how it would look like for example in case of |
@kisvegabor for The issue is for enumerated types, colors and the like which are mapped to integers, so from the return value of The issue might also be for the members of structured types (like For the enumerated types, the bindings generator does know that the expected type is e.g.
I would propose to go for solution 1, since it provides the most flexibility, is easy to implement and is 100% compatible with the micropython bindings. |
Actually, the change was so trivial that I have already implemented option 1: see this commit |
I’ll have to check out that code and get started on the builder. I have a basic GTK layout started so far. |
@AGlass0fMilk : any chance of using Qt (PyQt / PySide) instead of GTK? In my experience that creates cross-platform applications that have a more 'native' feeling. I also have quite some experience with it so could provide some help with the GUI builder, too. Obviously, of you are more experienced in using GTK, surely go ahead with that, and I'll try to support by providing the required Python bindings features. |
@rreilink Option 1 (what you already implemented) seems very flexible and easy to use for me too. Good idea! |
I'm not sure how needed this is, but it may be useful to introduce a standardized, parsable comment format for widget structs (and maybe other things?) to facilitate more reliable automatic binding and discovery of metadata (ie: what does a struct's field do?)
There are already doxygen comments but some things are missing tagged comments.
The text was updated successfully, but these errors were encountered: