[chirp_devel] Testing & Development

[Dan Smith]

> I'd like to contribute in my free time, which is admittedly sparse.  I
> was wondering if you're welcoming contributors

Surely!  There are a couple of other people submitting code as well.

> and if you had any
> accessible revision control so I can work from the latest and greatest
> when submitting patches.  Even if it's read-only, I'd prefer to work
> with the latest code.  I will be using linux, but will probably try to
> test any changes on windows before submitting any patches for you to
> review.

Yep, mercurial:

   http://d-rats.com/hg/chirp.hg

> * Inserting CB/FRS/GMRS frequencies (like vx-7 commander) - This is
> handy, and while I have it set up for my radios already, it is
> incomplete.

Okay, I just keep a CSV file with those things in it and import it into 
whatever radio I'm using.  However, bundling that with CHIRP and making 
it a push-button would be fine.

> * "Move up"/"Move down" buttons (like vx-7 commander) - This is good
> for moving frequencies without having to "copy", "delete (and move up)",
> "insert", "paste".

Hmm, I can't say that I understand what the purpose would be, but I 
haven't used the commander software.

> * "1-step convert" (read from radio type A, "convert", write to radio
> type B) - I have two manufacturers of radio, and while chirp handles
> both, it only handles both somewhat separately.  I'd like to be able to
> maintain 1 file, and just write to both radios.

Well, (for a clone mode radio) you'll have to download from the 
destination radio before you can upload back to it.  I just keep my 
common memories in a CSV file and then import them into each radio when 
I do updates.

With the Yaesu's, so much human intervention would be required for the 
"1-step" that I'm not sure it'll be worth it.  Too bad too, because with 
the Icoms and Kenwoods it could be rather automatic.

> * Toggle for Kenwood's "live" mode - If I want to "work later", I have
> to read, export to chirp native, work on that file, re-read, then
> import.  I'd much rather simply read, save to an img, work on that,
> write.  Or, my with the "1-step convert" option, have 1 file that I
> maintain with my frequencies that I can then easily write to multiple
> differing radios.

Well, again, for any clone-mode radios, you'll have to have an image 
before you can merge and upload.  The closest thing to an image of a 
live radio is a CSV (or chirp) file.  Perhaps just allowing the 
*appearance* of being able to upload directly from a CSV file to a live 
mode radio would suffice, although I think that it would likely confuse 
people with clone mode radios.

Maybe a subclass of the CSV radio would facilitate the distinction 
internally so that the UI could handle it appropriately and give the 
impression that the user can actually have an image of the radio.

> * Special settings for radios - Have a "settings" screen for things
> specific to each radio that is supported.  Things like what are
> available in VX-7 Commander for software free-banding the radio, setting
> the current mode, aro, vox, etc.

Rick and I have already done some preliminary work in this area for the 
VX-7, so we'll have to get busy finishing that up I guess.

> I also imported the last few versions you've released into a git
> repository and posted it on github.com which I will use as my starting
> point unless you have some place else I can easily get the source.  It
> can be found at https://github.com/Materdaddy/CHIRP

Please do use the mercurial tree as a base for patches.  I recommend 
using mq to manage them before sending.  You can send them to this list 
for review and inclusion.

I look forward to seeing what you come up with.  Feel free to ask your 
python and (of course) CHIRP code questions here.

Thanks!

-- 
Dan Smith
www.danplanet.com
KK7DS