Trim hats/joysticks as menu navigation aids on NV14

[vadimus-ca]

Can trim hats be used to help menu navigation on NV14?
Some menu items, especially bottom ones, are really tricky to be hit with a finger, thus either a bigger font (or bigger line spacing) should be used, or some other ways to make it more "clickable"

[raphaelcoeffic]

Can trim hats be used to help menu navigation on NV14? Some menu items, especially bottom ones, are really tricky to be hit with a finger, thus either a bigger font (or bigger line spacing) should be used, or some other ways to make it more "clickable"

The UI definitely needs some rework to be more usable. That being said, the only plan to use the trim hats as navigation is in standalone LUA scripts, as they are needed otherwise as trims.

[yds]

the only plan to use the trim hats as navigation is in standalone LUA scripts, as they are needed otherwise as trims.

FWIW, lack of trim hat navigation in standalone Lua scripts is a showstopper for us Nirvana ExpressLRS users.

e.g. after flashing EdgeTX on Nirvana, there's no way to trigger WiFi upgrade mode on an ExpressLRS TX, nor is it possible to change any parameters.. at least with Crossfire/Tracer it's possible to use desktop AgentX to make all the changes on the TX, no simple workaround like that for ERLS.lua tho..

would it be possible to trigger a trim hat mode switch between trim and UI nav functionality? perhaps something like a double long press of both trimhats to switch into nav mode and a double long press of both to switch back to trim mode?

[vadimus-ca]

the only plan to use the trim hats as navigation is in standalone LUA scripts, as they are needed otherwise as trims.

Why would anyone need to change trims WHILE in menu?

Unless it's not possible reassign trim hats handlers on the fly so trim function is definitely more important.

[vadimus-ca]

press of both trimhats to switch into nav mode and a double long press of both to switch back to trim mode?

Ideally, trimhats should be automatically - the scenario when the pilot needs to adjust the trim while changing model settings/using LUA seems a bit strange to me.

[yds]

press of both trimhats to switch into nav mode and a double long press of both to switch back to trim mode?

Ideally, trimhats should be automatically - the scenario when the pilot needs to adjust the trim while changing model settings/using LUA seems a bit strange to me.

maybe.. it gets tricky trying to guess what's best for every pilot.. speaking strictly as a quad pilot, having trim functionality on Nirvana disabled all the time so that the trimhats could be used for UI navigation would be a Good Thing:tm: -- but I can also see this being less than ideal for non quad pilots and their model configurations.. having a global toggle seems like a descent compromise, regardless if the toggle is a double long-press of the trimhats or a checkbox somewhere in the global config..

[yds]

I keep saying "double long-press of the trimhats" -- what I actually mean is a single long-press of both trimhats to toggle between trim and UI nav modes..

[pfeerick]

This is a duplicate of #622, but the title/focus is clearer on this issue. My 2c on the issue is automatic detection of input change for LUA is probably fine, but not for menus, as you may be in the menus making changes as part of your model setup and it would be annoying to have to go out of the model setup if you need to adjust trims, and then go back to whatever adjustments you were making.

And when I said simultaneous press on both joysticks before, naturally that is hard to detect, but it is effectively no different between press and hold one, and detecting the second being pressed at the same time... in either order ;)

I have looked at having it so trims switch over to inputs for lua when a standalone script is running, but have been stymied by not being able to check for standalone scripts the way it was previously done due to pre-emption changes, so hopefully Jesper can give me a clue as how to do it with the current framework. So painfully close! 😆