Shmuely/rotary gauge addons

[offer-shmuely]

additional enhancement to the new gauge

[pfeerick]

I came across this the other day, might be of interest? I hope this widget is starting to get a little less resource hoggy? 😁

https://luadoc.edgetx.org/part_iv_-_advanced_topics/optimization_tricks

[offer-shmuely]

I will check it
From tested, most of the 8% cpu that the widget take, is caused by setting the colors…. Strange

[pfeerick]

Thanks the for refresh... I will review this again tonight hopefully and merge it in. Sorry for the holdup!

[pfeerick]

Not sure if you realised, but it looks like tools.lua:42 will fail if RxBt is not present at all... i.e. if not used with a Betaflight/iNav setup...

Otherwise this is looking good. Is the positioning/color of the text for the middle guage when fullscreen intentional? It also looks like the widget doesn't like something about 2.8 when I tried the current nightly, but I suspect something is broken there, and it's not a problem with the widget since it works fine with TX16S on 2.7.1. We definitely need to see what's going on with Lua handling once there's more than one widget of these widgets running... it really starts dragging the radio UI responsiveness down - something isn't working properly in the radio firmware side.

[offer-shmuely]

tools.lua:42 will fail if RxBt is not present

fix with additional telemetry sources

Is the positioning/color of the text for the middle guage when fullscreen intentional?

can you please explain? I did not understand what is the issue here

It also looks like the widget doesn't like something about 2.8

still working with 2.7

once there's more than one widget of these widgets running... it really starts dragging the radio UI responsiveness down - something isn't working properly in the radio firmware side

I checked it on the start of the dev of this widget, it looks like a firmware GUI issue, I saw it with other widget as well,

did you see this bug as well?
there is an extra char after getting to getSourceName()

I did a workaround, but it is not pretty

[pfeerick]

can you please explain? I did not understand what is the issue here

Like in this screenshot... I was just asking if it (the value for the middle gauge) being big, yellow, and overlapping was intentional ;)

did you see this bug as well? there is an extra char after getting to getSourceName()

No (I didn't notice that one), but will look into it... it may be due to changes in string handling and a couple of cases weren't accounted for properly.

[offer-shmuely]

• if the value being big was intentional
  yes

• if yellow was intentional
  yes

• if overlapping was intentional
  no,
  it is a side effect,
  is it critical?
  I feel like the be number is more appropriate here, even if the overlap a bit

[pfeerick]

Nope, that's fine... I was sort of expecting it to be on the guage, if only for guaranteed contrast, although it would need to be smaller, but more user exposure will inform on if that's needed ;)

edit: And that merge commit msg wasn't quite right... this was updating the widget, not adding it (#60 did that)... oops!