[chirp_devel] FT1D and UI... seems to be OK, now. A bit of help still desired.

[Dan Smith]

> Thanks for the very prompt attention. I’m trying to add features to the ft2d.py (and ft3d.py) but they’re almost all handled in the ft1d.py, which radio has the same features (along with several other Yaesu radios.) And you’ve described a “feature” of my driver that I am vaguely aware of.
> In the radio, they are indeed in adjacent slots!
> 
> So, I looks as if I’ve fixed it by making the number field negative for specials (as I’ve seen in others’ implementations. Doh!)

It's really preferable to make them large positive numbers over the negative ones. The negative ones require some hoop-jumping in the UI which is uncomfortable and before I got that working I actually considered going and fixing all the drivers that use negatives. So if you're doing it, I'd much prefer you use memory numbers starting right after the last real one.

> Yay, so far. Tox was still happy with the new driver. (Unless you’re VERY fast, I’ve not done a git pull since this morning.) You pointed me in the right direction. It’s still a bit strange that it only shows up in the UI, but I understand that I confused it.
> 
> I think it’ll be a wonderful idea to add a tax  test to check for my (previous?!) bad implementation.

Yep, I wrote it a few minutes after I said I would and sent a link to the ML:

http://intrepid.danplanet.com/pipermail/chirp_devel/2023-June/007152.html

I hadn't merged it yet just because doing so will generate a build that won't have any user-visible changes. But, I just fixed a UI bug and so it's in the tree now along with that.

> Is it still necessary to refer to issue numbers, especially in this age of CHIRP_next? I suppose I can add bug and feature requests to cover my efforts.

Yes, please.

> So a little handholding will help me:
> 
> What’s a PR?

A PR (Pull Request) is Github parlance and mechanism for preparing a branch of changes and asking for it to be merged into my tree. Probably worth googling for some github tutorials for the general process.

> I presume that I should 
> make a branch, put in one set of changes, 
> then make another branch based on the first one to add another set of changes, 
> then make another branch based on the second one to add another set of changes, 
> continuing until everything is done. Then some how I communicate to you which change sets are available? 

A PR. You can have multiple (related) commits in a PR, but don't batch them up too far. If you have a couple small fixes now, we should get those merged (in a PR) separate from a big-bang feature addition.

> I also believe that FTM3200 radio, which inherits from the FT1D, should not be presently working. (the _mem_params arguments are in the wrong places to work right now. Should I worry about that at all? I tried to contact the driver folk listed in FTM3200.py via email, with no answer, but perhaps it’s not really used and so is moot?

Yes you should care and no we should not just break the ftm3200 driver. Even if you think it's already broken now, the more broken you make it the harder it will be for someone to pick it up later and get it fixed. I know people have been using that driver in -legacy at least, and some have reported that a firmware change broke cloning in some way, so there might be work to do. But please don't just break it and assume nobody will care.

--Dan