Default Widgets

[JimB40]

So I did review of Widgets included as default in 2.4

Those are currently available in release
Gauge - C in-build
ModelBmp - C in-build
Outputs -C in-build
Text - C in-build
Timer - C in-build
Value - C in-build
BattCheck - LUA SDcard
Timer2 - LUA SDcard
Ghost - LUA SDcard

All of in-build widgets need to be reviewed in terms of bad UI/UX (aligning, icons, colors, scaling etc.)
Of course those in-build need C dev resource that is precious :)

So first question is do we retain in-build widgets or move all of them to LUA SD card area passing development to LUA devs?

[lshems]

Very good question

[lshems]

Happy to invest time,but not when not supported by a proper decision

[offer-shmuely]

I belive that all the widget should be LUA based.
When transferring them to LUA, we will find that many API are missing to do the job
so the move will enforce the API to be full, a thing that later will give a real push to developer of "apps"
thing that today is very very limited

[DavBfr]

Maybe the first step is to figure out what APIs are missing and implement them, as well as the LUA replacement widgets.

[offer-shmuely]

If someone try to implement the current C++ widget, he will find some of the missing API

like:
Units for a telemetry/source value
Precision for telemetry/source value
When to divide the value by 100/1000/1024 to get a proper value

we also miss the info of “outputs” channel

[lshems]

Big part of that is already fixed. But yes, first check all API needs.

[DavBfr]

I can work on the C++ part if someone starts the Widgets

[pfeerick]

I think the current set of baked-in widgets should stay, but no more added - the basics are covered. Any major improvements to them should be done via Lua versions, i.e as @offer-shmuely has been doing already, and give people the choice of what they want - basic or extended/enhanced versions, while also making it so it's not locked bound to the firmware so changes can be made more easily by others. But, we also need to look at proper coding/memory management for the Lua widgets provided as standard as pointed out by someone else elsewhere, and make sure they only use memory when they're actually in use (i.e. use the loadable design).

[DavBfr]

@pfeerick I'd be interested to explore a way to repaint the widgets only when necessary, as they trigger a full screen redraw every 10Hz. Especially with the Lvgl library which has an invalidate mechanism. This should be implemented in the widgets too. The goal is to save some battery life when nothing is actually updated on screen.

[pfeerick]

A lot of different things (like that) are possible now that we are in LVGL land :) I would be surprised if there was an appreciable difference hat could be made in battery life here... the RF module and the LCD backlight consume the bulk of the power... but that's no reason not to do things smarter ;)

[lshems]

In principle you could limit the refresh to be done on the call of the display function of the widget. It is only called when visible, and I doubt that LCD commands are dynamic (drw.source won't update based on the source value between calls to the widget display function.).

What is the widget cycle frequency?

[DavBfr]

TOPBAR_REFRESH = 1000 / 10; // 10 Hz
OUTPUTS_REFRESH = 1000 / 5; // 5 Hz

[lshems]

Would that mean that the widget display function is called 10 or 5 times per second. When not waiting for input, this may be lowered, but when waiting for input this is already on the limit for responsibility.

So this all is pointing towards lua script control on updating the screen. Or checking if one of the draw functions is called at all in that cycle of the widget display function call.

[DavBfr]

Yes, that is the goal: have a new LUA/Widget method paint to draw the content. The current refresh would return a boolean true if anything is to be updated on screen.
Backward compatibility: if the method paint is missing, behave as before.
On the C++ side, if the widget opt-ins to the new interface, it can call refresh more often, but paint only when needed. And in all cases, lower the refresh rate when the screen is dim.

[offer-shmuely]

Another method will be a configuration on widget code to set the refresh rate requested.
e.g. flight cout widget, can be actually need painting only once second, or twice a second (2Hz)

is there a way to mesure the cpu and memory of specific widget while it is on the background or not used at all?

[lshems]

This would have me switch between 1000 seconds and minimum refresh rate everytime I want to refresh.

Lettung the Liz scripter set the pace seems better to me.

[DavBfr]

Here's the Outputs Widget in LUA: https://gist.github.com/DavBfr/b6e3619eaffd3e5a5f5828d72c957930
With the API changes here: https://github.com/DavBfr/edgetx/tree/add-lua-apis

[DavBfr]

All the C++ Widgets can now be replaced with LUA equivalents, the code is merged #2279 #2275 #2208

The basic widgets are implemented here: https://github.com/DavBfr/etx-tetris/tree/main/src Typescript transpiled to LUA.

• Timer with its background shape and progress indicator
• Gauge with all supported input values
• Outputs show the channels' output values
• ModelBmp which caches a resized model bitmap for faster drawing
• Text that can use the font size Widget Setting

The Widgets Settings and the Widget name can be translated and are not limited to a LUA variable.
Installing a Widget named "Output" it will replace the internal Widget with the same name.

[ValentinMumble]

@DavBfr Nice! How do you actually transpile TS to LUA? Thanks!

[DavBfr]

Everything is here: https://github.com/DavBfr/etx-tetris I guess someone used to typescript will find his way around.

[ValentinMumble]

Ah yes indeed, thanks again!

[offer-shmuely]

How do you overcome the missing api?
e.g.
How do you know the precession of the sensor?
How do you know if to divide in 100/1000/1024?
How do you know the units string?

[DavBfr]

The missing APIs have been added in #2279

[offer-shmuely]

Can you give a sample

1. How to know the precision of a sensor?
2. How to know if a field (like stick) need to be divided in 1024?

[DavBfr]

the constant FULLSCALE should be the stick precision. I don't know if there's a way to get the precision of a sensor.

[Shonkonray]

Hello together,

Sadly i am completly lost with things like compiling, transpiling and all the stuff, but i want to take a little sneak peek at LUA scripting.
For me its easier to learn and grasp the idea by editing something existing and working. I want to try my luck with the timer and outputs (i want to modify them a bit) and see if there is any hope (and fun) for me to learn LUA.

Therefore i would kindly ask for someone to transpile the default widgets (at least outputs and timer) to functional/working LUA scripts. 🙏