Hi Jim,

Sorry for the delayed response here.

On Aug 16, 2018, at 4:15 PM, Jim Lieb via chirp_devel chirp_devel@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