Include the lvgl-stubs in the Stubs Playground

[Josverl]

@kdschlosser

I have recently created a tool and PoC for better (online) editor integration of stubs for MicroPython development.

I would love to include the lvgl-stubs in that tool as selectable option, but want to check first if that is OK.

LVGL @ Stubs Playground
( by adding the lvgl-stubs the errors will go away - and get replaced by docs and param info as tablestakes for any IDE nowadays)

The tool is a static site - so integration in the build steps could be straightforward, as you have most of the stubs already.

I'm not sure how much the delta of the rest is with stock MicroPython - but I expect that re-generating stubs for any changed modules should be straight-forward if needed.

I remember for a few years back that stubbing the lvgl module itself was an undertaking - but IIUC that is now generated during build ?

anyway - first things first : Would you like to make this work ?

[kdschlosser]

the stubs file is not 100% correct. It needs to have work done to it to get it right. The stub file is generated during the build for LVGL. the other stub files are hand keyed and they do need to be checked for correctness. I have forgotten to update them when a change was made.

[Josverl]

Not perfect is much better than none at all.
For that reason the playground has a [Report Issue] button that creates a populated issue, so it becomes simpler to gradually improve.

Currently they all go to the micropython-stubs repo , but should not be too hard to switch the target for that that based on the selected stubs.

[Josverl]

See #573 for fixes to stub_gen to produce a clean lvgl.pyi

[kdschlosser]

attach a copy of the generated stub file. just add .txt to the end of the file name to attach it. I will check it to see what needs to be fixed. Is that cool?

[kdschlosser]

IDK if you are familiar with this repo...

https://github.com/josverl/micropython-stubs

[Josverl]

Kindoff - I created it :-)

[kdschlosser]

Yeah I noticed that after I posted the link.

[kdschlosser]

There is a new MicroPython plugin that has been made for PyCharm and it is a vast improvement over the one written by JetBrains. They commented the the use of your stub files. I opened an issue at the repo for it with a suggestion to add support for my binding. I also mentioned that the build script really simplifies the compilation process of MicroPython and it could be changed very easily so it could be used to compile only MicroPython without the LVGL binding. You have used the build system and they are also familiar with who you are, maybe you may want to drop a line in the issue letting them know about the stub generation for this library and that you are currently in the process of working on it...

Might even be able to add stub generation directly to their plugin so it will generate the stub files on demand.

Here is the link...

https://github.com/lukaskremla/micropython-tools-jetbrains

[Josverl]

Yes, I know Lukas, And I think Paul author of a similar tool for VSCode will be interested as well.
To enable that wewill need to think about packaging.
I have machinery for that, so that just needs agreement.

Edit
Lukas' plugin is written in Kotlin, and has no dependency on Python, so dont think that on-demand generation would be a fit.

Is there much variation? ( The 3 builds I tried resulted in identical stubs)
It should be possible to enable sections of the stubs based on defined constants, similar in effect to preprocessor MACROs.
Most typecheckers support that in some way.

[kdschlosser]

I can handle modifying the build script so it can run to just compile MicroPython. It's already written to compile for most of the other boards that are supported by MicroPython

The only reason why the binding is not able to be used by other MCU's is because of the lack of the bus drivers. I don't have have knowledge of the other boards SDK's and I don't have the time to learn it either. I was hoping that someone would come along and be willing to tackle some of the other MCU's but that has not happened.

It would be nice to have direct support for this binding right in VSCode or in PyCharm where the user would be able to select the settings they need and it would compile the firmware for their board with the drivers needed to get it up and running. Part of the build system is the ability to use a toml file to declare everything that is needed to produce a firmware with all of the needed drivers in place to have them up and running in no time. Can even go the full distance and have it compile the binding with LVGL so it could run right inside of an IDE with the framebuffer data being passed to the plugin in the IDE so an interactive preview could be given for the user to test or to see how the UI is going to look without needing to flash an MCU. The MicroPython binary can be started as a subprocess and by leveraging an environment variable that MicroPython uses we can direct the frame buffer data to the stdout of that subprocess so the parent process can read it.

[Josverl]

That are 5 other side projects in that one post 😎

I like the vision, and can help with some aspects, but certainly not all.

Mpbuild is my goto for building just about any board, but needs some adjustments to better support out of tree builds such as this project. Matt is open to improvents in my experience.

Simplifying the plumming would lower the barrier for other contributors, and may improve build times as well.

[kdschlosser]

That are 5 other side projects in that one post 😎

Yes and no. they have attachments to each other. In order to do the preview window thing you would need to have a compiled binary for the machine it is running on. That would be dependent on being able to compile the binary properly which is what a proper build script would handle. IDE integration of MicroPython requires having stub files which is where what you are doing now steps in which is where the build steps in as well.

I have not written stub files for all of the individual drivers and it is something that really doesn't need to be done. Also exposing all of the drivers to the IDE when a user is only going to be using a single one of them would be a waste. The drivers should be added to the project in a manner that makes it visible to the IDE when the user selects what driver to use. If a preview window existed writing a wrapper around the driver as to not do anything with the pins but still provide the majority of the functionality that the driver provides would not be that hard to do.

I have never heard of mpbuild... something I will need to check out I guess...

[Josverl]

https://github.com/mattytrentini/mpbuild

[resnbl]

Just my $0.02 here: I inserted @Josverl 's version of stub-gen.py into my local build and the result is now useable with the Zed IDE and basedpyright/ruff type checking. (The List[void(] error in the original killed it for me.) I was trying to update the script myself when I tripped over this thread, but I don't really have the level of understanding to do this properly.

There are still some issues, but at least the majority of it is available in my editor.
Thank you for this work!

[kdschlosser]

I am going to need to do something because the newest release of LVGL broke the script that outputs the json data that is used in the generator. It might be time to scrap the current script generator and stub generator. The current one is a fickle animal and it breaks very easily. I have not wanted to tackle that beast on my own because it is a pretty large undertaking to do. I have thought about hard coding the binding code as I think this would be easier fix if something breaks. LVGL's API for the most part is fairly stable so from a maintenance standpoint it would not be that hard to work with.

if anyone wants to help out with either writing a new script generator or hard coding the binding lemme know. It's really not something I want to tackle by myself.