[chirp_devel] settings.py help

[Dan Smith]

Hi Jim,

Sorry for the delayed response here.

> On Aug 16, 2018, at 4:15 PM, Jim Lieb via chirp_devel <chirp_devel at intrepid.danplanet.com> wrote:
> 
> I'm writing the KG-UV9D Plus driver. I've got the memory channel and basic settings under control but there are a few radio features that need UI support. I've been looking at various other drivers and the settings.py (and friends) and haven't found what I'm looking for.
>  
> There are a few settings that are really tables, similar but much simpler than the memory tab. For example, there are scan groups which have a name, a starting memory channel and and ending channel. They are described in the following memory template frag:
>  
> #seekto 0x940;
> struct {
>     struct {
>         i16 scan_st;
>         i16 scan_end;
>     } addrs[10];
>     u8 x0968[8];
>     struct {
>         char name[8];
>     } names[10];
> } scn_grps;
>  
> Yea, it is clumsy and indicates that the firmware coders were sleeping in Data Structures class but in the end, it should map to a 3x10 table with header, something on the order of:
>  
> name | start | end
> ===========
> airport | 108 | 136 |
> ....
> ===========
>  
> This would be a RadioSettingGroup or ??? under the settings tab.

Yeah, I would probably do a RadioSettingGroup for "scan lists" and then do a bunch of settings for "Group 1 name", 'Group 1 start", 'Group 1 end", etc. We don't really have a much richer settings interface than that really. You could also do a group for "settings" and then a group under that for "Group 1" and then just have three settings per group. I think that will nest properly in the UI.

> I have another which is the caller id table.  In this case, it is a 2x20 table with the first col being a 6 char name and the second, a DTMF 6 digit code:
>  
> #seekto 0x940;
> struct {
>     struct {
>         i16 scan_st;
>         i16 scan_end;
>     } addrs[10];
>     u8 x0968[8];
>     struct {
>         char name[8];
>     } names[10];
> } scn_grps;
>  
> Again, this would be a table in a RadioSettingGroup.

I think this might be better with just two groups, one for the names and one for the codes.
>  
> I really want to keep this within the driver ATM and not go off hacking settings.py and the GTK stuff (yet) but sticking to the (as I understand) the derived classes in settings.py gives me little more than lists of simple labeled item widgets.

I would just go simple (and ugly) first. I'm not sure I want to get into having a table in settings, but maybe some smaller grouping construct that will just make it easier to express to the UI that "these three things should share a row" would be enough?

--Dan