EdgeTX
feat: add ability to set source for backlight / brightness and volume controls
Set a Pot, Slider or Switch to control brightness without using a special / global function.
If a Backlight special / global is defined it will take precedence over this new radio setting.
TODO:
- [x] limit selection to Pots, Sliders or Switches Companion radio settings editor.
@elecpower When you have some time could you look at the companion side please. I have implemented the YAML read/write and added the control to the radio settings edit page.
It needs to be updated to limit the backlight control to only select Pots, Sliders or Switches,
I think this does go against the whole logic, where things are done throuht SF. Now it is a settings, a GF, a SF, for people to understand what happens , it becomes a nightware.
What happens if you usually don't need to use the pot, but this new model needs it for a gyro gain for example ?
Looks like #2256 won't be needed anymore then, and the issues it addressed can be moved to here...
I think this does go against the whole logic, where things are done throuht SF. Now it is a settings, a GF, a SF, for people to understand what happens , it becomes a nightware.
No, it gives a mechanism to it without using GF or SF. If you need something more advanced, you use that instead.
What happens if you usually don't need to use the pot, but this new model needs it for a gyro gain for example?
Same could be said for Brightness GF... i.e. you wouldn't configure it globally, or you use it for both.
This PR #6684 is interesting and could be helpful to band-aid the primary problems in SF backlight I observe since introduced in EdgeTX ~v2.6.x. But this PR still does not provide a complete solution to allow setting both an alternate backlight brightness and control... Please consider/investigate issue #5851 as well.
Thank you & Happy to test :-)
As I poke with this a bit I find myself agreed with @3djc. We are not talking about a menu navigation button, this is normal user controls and they should be left for user to configure in SF / GF.
The commit above fixes the source list. The dynamic update part is a wip
Thanks for that. A couple of things:
- Tilt X & Tilt Y should not be selectable
- Negative / inverted values should be selectable.
- Tilt X & Tilt Y should not be selectable
- Negative / inverted values should be selectable.
Noted and will incorporate
Custom function switches not listed correctly and will be addressed as part of the larger issue
For consistency then, shouldn't the same apply to audio and variometer volumes ?
For consistency then, shouldn't the same apply to audio and variometer volumes ?
One step at a time.
Looks like I need to rename the source item model to a generic name. I'm open to suggestions.
Looks like I need to rename the source item model to a generic name. I'm open to suggestions.
ControlSourceItemModel
A few thoughts as I notice this does not fully address problems remaining in SF backlight...
To restore full SF backlight functionality (pre EdgeTX ~v2.6.x.): Does this allow global variable to quickly switch between user defined brightness/volume settings? Can we add switch support to quickly force backlight to stay ON?
What about making it so there is some indication that a SF/GF is set (which takes priority over these settings/invalidates the configuration)? i.e. disabling the control / msg at the side?
Do you think the volume bar / on brightness sliders should move in sync with the control if it is configured? Or would that confuse, as it could be construed as "changing" the volume configured?
What about making them "always working" when configured... i.e. say if you startup with throttle warning active, brightness and volume can be adjusted even there? Basically, from the moment you know they are configured, and there isn't a conflicting configuration, use them.
What about making it so there is some indication that a SF/GF is set (which takes priority over these settings/invalidates the configuration)? i.e. disabling the control / msg at the side?
Do you think the volume bar / on brightness sliders should move in sync with the control if it is configured? Or would that confuse, as it could be construed as "changing" the volume configured?
Brightness ON/OFF sliders set the range for the brightness control (whether it's direct or via SF/GF). Volume should also be able to do this; but needs some work (separate PR).
What about making them "always working" when configured... i.e. say if you startup with throttle warning active, brightness and volume can be adjusted even there? Basically, from the moment you know they are configured, and there isn't a conflicting configuration, use them.
Not practical right now as both volume and brightness settings require the mixer to be running.
Brightness ON/OFF sliders set the range for the brightness control (whether it's direct or via SF/GF). Volume should also be able to do this; but needs some work (separate PR).
This is why I specifically said "on brightness", as the SF/GF/direct? control effectively relates to that. But let's leave that for a separate PR/discussion anyway, as there are some other minor UI tweaks that could be done around there.
Same with the brightness and volume settings being tied to the mixer. I understand why it is done that way but IMO that needs to change, but does not need to be right now.
The warning seems fine, but will probably need to be given its own translation string in the future, as that probably won't work so well for non-latin languages.
So it's just something similar for companion and this is ready to merge?
The override string is already translated, just added SF/GF in front of it. A separate string could be added if the translators think it would help.
It's ready as far as I am concerned, other than companion warning..
just added SF/GF in front of it.
Which is the problem... does chinese, hebrew, etc, use SF/GF, or non-latin characters ;) And some languages the words are in the other order. Hence why it will need to be translated later, and probably rephased to "Overridden by SF/GF" when it is done (space permitting).
Need to think about that one more... might just have to be to individual translators to work out something to fit space limits (i.e. suitable abbreviation in native tongue).
How about removing the ability to edit it on B&W if overridden? you get that space on the right back, and then use most of the rest of line for warning msg? i.e it could say "SF/GF Active" or even just use the "Override" translation there... and leave it to the manual to explain what that means?
I don't understand the choices made on that source list. What are the chances switch value actually match what the user wants, especially on a 3POS ??? If you want a 20, 70, 100 for example, you need to make a curve on chan, but you cannot select that, you only have access to 0,50,100 of switch