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

[chirp.cordless at xoxy.net]

Responses inline.

On Apr 24, 2014, at 8:33 AM, Tom Hayward - esarfl at gmail.com  wrote:
> On Thu, Apr 24, 2014 at 8:15 AM,  <chirp.cordless at xoxy.net> wrote:
>> 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:
> 
> Let me try to understand this a little more thoroughly. Correct me if
> any of the following is not true.
> - The logic you are suggesting already exists in import logic

No, that's not the case. The current import_logic is what's actually
breaking it, although I don't think it needs to change.

The current import_logic code sets rtone = ctone if tmode is TSQL,
without any concern that rtone is a user-suppled value and ctone is an 88.5
default supplied by csv import because there is no cToneFreq column.

> - Import logic doesn't help in your case because you have an out-of-spec CSV

If there were a cToneFreq column, import_logic would be a no-op,
which would not so much 'help it' as 'not break it'. I think it would
actually save the day here if cToneFreq were present but rToneFreq
wasn't.

> Where'd you get a CSV without all the Chirp columns? (just curious)

I created a spreadsheet in Libre Office with the memories I want
to load in my radio, and saved as csv. The column heading values
were obtained by exporting something from Chirp some time ago.
Recognizing that for me, and Id expect 90+% of users, there is
no utility, just cruft, in having separate rToneFreq and cToneFreq
columns, making my speadsheet wider and harder to maintain etc.,
I just left cToneFreq out. It worked fine until I wanted TSQL.

I also leave out URCALL,RPT1CALL,RPT2CALL and a few others.
It's great that Chirp provides an extensible input method that handles
a lot of user's requirements, but smart defaults make for a good
user interface.

> We already have lots of support for interpreting various differences
> in CSV. I don't see how supporting more oddities (like a missing
> column) is a problem--go for it!

I'll take that as a go-ahead. Bug and patch coming, probably later
today if I can get to it.

> I wonder if there is a better way to handle this. Like, if a CSV file
> is detected as to not be the standard format, maybe we pipe it through
> import logic so we don't have to essentially duplicate those rules in
> the CSV driver.

Again, import_logic doesn't fix this problem, it actually triggers it.
I think it's actually doing what it's supposed to be doing.

Imagine someone with a radio with separate rtone/ctone importing
to a radio like my FT-60 that only has one, with a TSQL channel.
That, and the reverse, is what _import_tone() in import_logic.py is
there to handle, and nothing else. 

Now suppose that one of the defined memories uses TSQL,
rtone = 107.2, and ctone = 88.5 (deliberately). The existing code
sets rtone = ctone. I assume that that's what's wanted, since that's
how it's coded.

How can this piece of code tell the difference between this case
with a real radio, and mine with a CSV pseudo-radio?
Why should it?

IMO, the place to recognize a "missing column oddity" in a csv
file is the csv import. The csv import code is already handling
the case of the missing column, just sub-optimally.

-dan