[chirp_devel] RFC settings import export

Tom Hayward
Mon Dec 30 10:10:44 PST 2013


On Mon, Dec 30, 2013 at 9:36 AM, Robert Terzi <rct at r-t.org> wrote:
> On 12/30/2013 1:03 AM, Tom Hayward wrote:
>
>> It makes more sense to me to begin by supporting Import/Export of
>> settings via img from identical radio models. For example, import
>> uv5r.img into another uv5r. For this you will not need any CSV
>> encoding or translation between models. I think this feature would
>> satisfy most user's need for settings import.
>
> Couldn't that use case of moving settings to an identical radio already
> be handled by just using the source image after importing the frequencies
> from the destination radio's image?

As Jens mentioned, there's other stuff in the radio img you don't want
to blindly copy, like calibration data. I was suggesting copying only
the known settings bytes. Since it's the same model, you can simply
copy the settings blob without any conversion. The UI for this feature
could simply be a checkbox under the frequency import table that says
"also import settings?".

> The recently requested use case was the possibility of improved accessibility
> for the visually impaired by allowing CSV export and import.  As mentioned, this
> would need 100% fidelity in the export and re-import to be useful, so would be
> difficult to achieve, especially with CSV.

I have yet to understand this use case, so I was ignoring it. Can
anyone explain how putting settings in a CSV improves accessibility?
Guessing here, but is LibreOffice spreadsheet-to-speech really that
much better?

I don't see how CSV is going to be a reasonable or effective way of
encoding settings information.

> The use case that I haven't seen mentioned, is exporting to some textual
> representation to facilitate settings comparisons.  This is useful for
> not only comparing two radios, but also for determining what settings have
> changed over time on a single radio.  I use G4HFQ's FTBVX8 software in that
> manner.  The settings user interface is table oriented and can be exported
> to text files making compares possible, even on radios with a lot of settings
> like the VX-8.

I've never seen this. I'm curious how settings are put in a table
format. Key-value seems more natural.

> As this can be very useful for diagnostic purposes, I'd be interested in seeing
> some sort of textual export/report, even if there were no import, initially just an
> additional developer function.  More of the settings meta data would need to be exposed,
> which would wind up providing additional documentation for each radio's settings.
> I'm guessing that is where Jens J. is headed recently asking about doc strings for settings.

It probably wouldn't be too involved to add a JSON output to
RadioSettingGroup. You could run a diff on this. This makes some sense
to me for power users, but not for accessibility.

Tom KD7LXL



More information about the chirp_devel mailing list