Open LUA wishlist

[gagarinlg]

Since there are plans to overhaul the LUA API, we should start a discussion with Lua devs, what they want and expect. The place for that discussion is here.

What is already planned:

• switch to 5.3/5.4, which allows for luac compatibility between simulator and radio and a myriad of other improvements
• access to colorLCD UI elements, making scripts faster and better integrated on the color lcd radios
• LUA API clean out and general improvements

[voltangle]

I want to suggest a system that will greatly improve the user experience with Lua scripts, which will be called EdgeTX Packages.

So, how currently script management is done in EdgeTX?
To install a script, users go to the repo/download page, look at the instructions, download a .zip file with all required files, and drag the contents of that .zip file so that every file will be automatically placed where it should be. Easy, right? Yea, but now comes the hard part, deinstallation.
To uninstall a script, a user should search the entire SD card for files related to that specific script and manually purge them. It's far from ideal, and is basically a chore. I don't like it at all. And to fix this, I suggest a solution: EdgeTX Packages.

What is that? Well, you know how apps are installed on your Android phone using an .apk file? It's basically the same thing, but for EdgeTX: it's a file with an .etxp (EdgeTX Package) extension and is basically a .zip file with all files for that specific script, or, well, package. All packages should also have something like a info.json or info.yml (probably the latter so it would not be required to waste space by also adding a json parser alongside a yaml one) that will contain all info about a package like name, ID, author(s), version, homepage, repo, etc., and most importantly, the install/uninstall actions. It can be written two ways: a simple way, or a not-so-simple way. A simple way is just listing out files that should be installed and where should they be installed. A not-so-simple way is using custom installer/uninstaller scripts that will do all of the heavy lifting.

With Packages introduced, EdgeTX can also make something resembling an App Store or just a repository with software verified by the EdgeTX-es team, with access directly from the Companion GUI, where you can also add third-party repositories, just like Taps in Homebrew (a package manager for macOS).

Manually installing a package will be done using the File explorer, just find the file, bring up the menu, and select "Install". This can also be called "sideloading", because a package is installed outside of any repository.

Btw, if some software is simple enough that it fits in just one file, then they can be implemented as just a standalone script, and everything that was contained inside the info file will be fit inside that script, just as variables.

All third-party software management will be done through some sort of a "package manager", that will, well, manage everything. The Tools screen will contain a list of installed packages (btw these packages can be just apps, or even something like a "library"). To run old scripts that have not been updated for the new system, a user can go to the file explorer and manually run the script from there by finding it in the storage. That method is not preferred, because it can possibly mess up everything that was already done by the system and mess with other scripts.

So that's EdgeTX Packages. A system, that can greatly simplify the lives of users and developers.

Oh, wait, I forgot to mention how developers will use all of that! Surely they will not manage everything in their project manually, right?

Right! They won't! There will be a CLI tool for devs to manage an EdgeTX project, and also a VS Code extension, to simplify their workflow even further.

I hope that ETX devs will like this proposal and that would be brought to the ETX project somewhere around the 3.0 milestone :)

Oh, and yea, I am willing to help implementing all of that, I am fairly experienced with STM32 MCUs(I'm still a rookie but I know all the basics at least and how it all works) and C/C++ embedded programming!

[voltangle]

Understood, already writing

[frankiearzu]

Agree that some package management could be usefull. With limited memory and more complex LUA scripts, they will probably not be a single file, so that we have to dynamically load "parts" of the LUA as needed. For example, the Wizards, main LUA then loads the specific Plane,Glider, Lua scripts. If memory is still a problem, you will end up having smaller chunks of LUA script. Keeping all that files orginized in a package would be great.

[frankiearzu]

That will be most welcome, Jeti already have a storage space for applications The “flight” widget that I wrote, on jeti it save the data on the widget storagespace, on edgeTx i am saving it on GV9

Can you point me to your script, i would like to see how you did the storage management

[offer-shmuely]

Mine:
https://github.com/offer-shmuely/edgetx-x10-widgets/blob/master/WIDGETS/Flights/main.lua#L234

On Jeti they save like this:

local function counterSwChanged(value)
counterSw = value
system.pSave("counterSw", value)
end

[voltangle]

https://www.craft.do/s/xoyTaG2zloBG7G Started writing a full-on paper on this proposal, which (i think) already became the main paper with all planned changes for third-party software in 3.0

[MarivelSwickheimer6pv]

It's great to see that there are plans to overhaul the Lua API and that there will be discussions with Lua developers to gather their input and expectations. Moving to version 5.3/5.4 and providing access to color LCD UI elements sound like promising improvements, and a cleanout of the API will likely lead to better overall performance and user experience.

[TaynaPill8o]

Starting a discussion with Lua developers is a great idea to gather feedback and ideas on how to improve the LUA API. Here are some potential questions to start the discussion:

What are the most common use cases for Lua scripts in the simulator and radio?
What are the biggest pain points in the current Lua API?
What features would you like to see added to the Lua API?
Are there any Lua libraries or frameworks that you would like to see integrated into the API?
How important is compatibility between the simulator and radio Lua APIs?
Are there any specific performance improvements or optimizations that you would like to see in the Lua API?
How important is backwards compatibility with the current Lua API?
How would you prioritize the different improvements and features for the Lua API?
These questions can help start a productive discussion with Lua developers and gather their feedback on the current and future state of the Lua API.

[offer-shmuely]

Adding to the list:
Widget settings screen:

1. More that 5 settings
2. Setting can have a description
3. Allow to choose real channel (today it is a mix, not a channel)
4. Allow to select inverted channel
5. Allow to select switch (on all 3 positions
6. Allow the user to save some of the settings globally, i.e. for all of the instances of the widget (on this model and other models)
7. ComboBox on setting. I.e. widget can define a list if values to choose from

[NubiaMeldrumDN]

tarting a discussion with Lua developers about the future of the LUA API sounds like a good idea, and it's great to see that plans are already in motion to switch to 5.3/5.4 and improve access to colorLCD UI elements. A clean out and general improvement of the LUA API will likely lead to better performance and more efficient scripting on the radio.

[wsnfly]

I hope to convert the telemetry data received by the remote controller into MAVLINK packets and then output it from the UART port at the bottom of the remote controller (T16).