Re: [chirp_devel] [PATCH] [tg_uv2p] Inhibit keypad lock when in dual watch or crossmode. Fixes forth issue in #9939
Hi Dan, Thanks for the feedback.
Ideally I would like to reject it at the user (UI) level - is it possible to have co-dependent setting values, i.e. keypad lock has 2 possible values ("locked", "unlocked") if rx_mode is "normal" (not DW) and only "unlocked" if rx mode is not "normal", and similarly for rx_mode ("normal", "cross mode" and "DualWatch" when keypad is unlocked and only"normal" when teh keypad is locked)?
Otherwise, I would probably prefer just to have a comment stating that the radio will not unlock via its keypad when in DW etc.
Regards, Ran
Ideally I would like to reject it at the user (UI) level - is it possible to have co-dependent setting values, i.e. keypad lock has 2 possible values ("locked", "unlocked") if rx_mode is "normal" (not DW) and only "unlocked" if rx mode is not "normal", and similarly for rx_mode ("normal", "cross mode" and "DualWatch" when keypad is unlocked and only"normal" when teh keypad is locked)?
Well, like I say, if you're setting the dual-watch setting to on, you can raise an exception. So, if that setting is being set on, quickly check the keypad lock thing and raise if it's on. Same for the other - don't let the keypad lock be set if dual-watch is enabled. That has the same effect as tying them together in the UI, right?
If I'm misremembering how well that would work, then I'd say we just need to not obsess over that level of detail. Keeping the UI driver-independent is important and, of course, not all things can be represented in an abstraction.
--Dan
Hi Dan,
And again, thanks, Indeed the exception is a good way to get the user's attention, I submitted a new patch, using exceptions and checking the actual settings value (not based on order).
Ran
On Fri, Aug 12, 2022 at 5:34 PM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Ideally I would like to reject it at the user (UI) level - is it
possible to have co-dependent setting values, i.e. keypad lock has 2 possible values ("locked", "unlocked") if rx_mode is "normal" (not DW) and only "unlocked" if rx mode is not "normal", and similarly for rx_mode ("normal", "cross mode" and "DualWatch" when keypad is unlocked and only"normal" when teh keypad is locked)?
Well, like I say, if you're setting the dual-watch setting to on, you can raise an exception. So, if that setting is being set on, quickly check the keypad lock thing and raise if it's on. Same for the other - don't let the keypad lock be set if dual-watch is enabled. That has the same effect as tying them together in the UI, right?
If I'm misremembering how well that would work, then I'd say we just need to not obsess over that level of detail. Keeping the UI driver-independent is important and, of course, not all things can be represented in an abstraction.
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
participants (2)
-
Dan Smith -
Ran Katz