[chirp_devel] Proposal to make use of TSQL in csv import friendlier

[chirp.cordless at xoxy.net]

Tom,

Thanks for the agreement on the direction, and I'll be happy to
implement any way that makes sense.

The import_logic function _import_tone() isn't setting rtone to 88.5,
it's setting it it to ctone, which csv import set to 88.5 because there
isn't any such column in the csv, and then because the CSV pseudo
radio is defined as having both rtone and ctone:
        # If copying from a radio with separate rtone/ctone to a radio
        # without, and the tmode is TSQL, then use the ctone value

I figured that's there for the case of real radios with separate rtone/ctone
and don't want to break that. I considered having the csv import logic
do the same check for a "cToneFreq" column I did in my suggested
patch, and then if not present, set
rf.has_ctone = False
in the CSV pseudo-radio's features.

But I thought the symmetric "if there's only one of [ rtoneFreq, cToneFreq ]
use it for both" approach would cover a multitude of user confusion.
As you said, if one tone value is supplied, it's likely to be a better default
for the other than 88.5.

If you still want it in import_logic, outline an approach that doesn't
break the general case and I'll get to work on it.

-dan

On Apr 23, 2014, at 11:11 PM, Tom Hayward - esarfl at gmail.com  wrote:
> On Apr 22, 2014 12:49 PM, <chirp.cordless at xoxy.net> wrote:
> > But I'd like to propose a very specific change to csv import, such
> > that if exactly one of the columns rToneFreq and cToneFreq exists
> > in the csv file, that the value in that column be used for both rtone
> > and ctone.
> 
> Makes sense to me. The rTone value is a much more useful default than 88.5.
> 
> This could probably be done in import logic, not CSV.
> 
> Tom KD7LXL