[chirp_devel] horizontal radio settings
Is there a way of controlling the positioning of settings? Can I make the display like: Setting A Setting B Setting C Setting D
vs the vertical default of Setting A Setting B Setting C Setting D?
actually what I want to do for the tyt h9800 band limit display (and potentially future setting) is something like band limits Band rx low rx high tx low tx high 30 mhz [ 26.000000] [ 33.000000] [ 26.000000] [ 33.000000] 50 mhz [ 47.000000] [ 54.000000] [ 47.000000] [ 54.000000] …
Thanks.
James N1DDK.
Is there a way of controlling the positioning of settings? Can I make the display like: Setting A Setting B Setting C Setting D
vs the vertical default of Setting A Setting B Setting C Setting D?
No, not currently. Feel free to take a shot at changing the code to generate that box. Since the radio settings are free-form and totally radio-dependent, it's just easier to keep that dialog simple.
If you wanted, maybe a multi-setting class could be created that would contain multiple primitive setting elements, and then the UI could be taught to lay those out in an HBox? Then you could have your driver create one multi-setting for each band, which would have four elements. That would probably be how I'd go about it...
--Dan
Hi Dan, Thanks for the feed back. I was looking at what was available in settingsedit.py and settings.py and did not see any existing infrastructure for what I wanted to do , but wanted to be sure I did not miss anything.
For now this display will just be a long list like other settings. I don’t think I want to hold up an initial cut at the h9800 that Jens and I have been working on to build a new setting class.
Thanks,
James
On Dec 30, 2014, at 2:18 PM, Dan Smith dsmith@danplanet.com wrote:
Is there a way of controlling the positioning of settings? Can I make the display like: Setting A Setting B Setting C Setting D
vs the vertical default of Setting A Setting B Setting C Setting D?
No, not currently. Feel free to take a shot at changing the code to generate that box. Since the radio settings are free-form and totally radio-dependent, it's just easier to keep that dialog simple.
If you wanted, maybe a multi-setting class could be created that would contain multiple primitive setting elements, and then the UI could be taught to lay those out in an HBox? Then you could have your driver create one multi-setting for each band, which would have four elements. That would probably be how I'd go about it...
--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
I'm pretty weak on MVC patterns, but my understanding is keeping a clean separation between radio drivers (model?) and the UI (view/controller?)
Could this be done from radio driver if we can signal some sort of logical partiioning? Ideas: Allow RadioSettingsGroup (RSG) nesting. Multiple RSGs within a tab (i.e., top-level RSG) would signal UI/view to attempt to render one nested RSG per column. Or maybe same idea above as RSG subclassing, i.e., RadioSettingsSubGroup. Or maybe appending something akin to a column break, e.g., RadioSettingsGroupColumnBreak, to the list which would signal UI to draw to a new column in the list.
While we are on this subject, I have desired a (long) description field for some radio setting values which would act like a tooltip.
Another desire was the ability to have a label or (read-only) textarea field for informational purposes in the UI.
On Dec 30, 2014, at 1:54 PM, Dan Smith dsmith@danplanet.com wrote:
For now this display will just be a long list like other settings. I don’t think I want to hold up an initial cut at the h9800 that Jens and I have been working on to build a new setting class.
Sure, sounds good. Thanks!
--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
I'm pretty weak on MVC patterns, but my understanding is keeping a clean separation between radio drivers (model?) and the UI (view/controller?)
Right.
Could this be done from radio driver if we can signal some sort of logical partiioning? Ideas: Allow RadioSettingsGroup (RSG) nesting. Multiple RSGs within a tab (i.e., top-level RSG) would signal UI/view to attempt to render one nested RSG per column. Or maybe same idea above as RSG subclassing, i.e., RadioSettingsSubGroup. Or maybe appending something akin to a column break, e.g., RadioSettingsGroupColumnBreak, to the list which would signal UI to draw to a new column in the list.
You could do it with the group I guess, but logically it's more of a multi-value setting element I think. Setting is just a subclass of Group with one thing, so having a subclass that stores one and a subclass that stores a bounded set makes sense to me.
Later we could use nested groups to add tabs within a setting group page, and thus doing this for a band's hi/low settings would confuse that. The thing he wants is really "the 30m limits, which is composed of a high and low value".
While we are on this subject, I have desired a (long) description field for some radio setting values which would act like a tooltip.
We have the ability to store the __doc__ bits with the RadioSetting/Group, which is what that was for. I thought the settings editor would use those for tooltips, but maybe that never got implemented?
Another desire was the ability to have a label or (read-only) textarea field for informational purposes in the UI.
Sure, a ReadOnlyStringValue class that looks just like string but causes the UI to emit a Label instead of an Entry would be easy. I think Tom was saying he wanted something like that recently.
--Dan
participants (3)
-
Dan Smith -
Jens Jensen -
jml