[chirp_devel] Comments on a UI rewrite

[James King]

> Hrm, well, I don't have one here to poke at, but it sounds like you
> probably did what I would have. Have you tried the MCP program to see if it
> appears to only operate at 9600?
>

I just tried MCP-4A on my Window laptop, there's no options in it to set
the baud or see what it's using.  Also, while the CP210x virtual comport
driver properties allow you to change the port's baud from 9600 to, say
57600, there didn't seem to be any change in cloning speed by doing so, nor
could I see anything relevant in the USBPcap traces I took during a couple
of tests.

I guess the next question then is: why did you like the live mode when it's
> so slow? Is there something bad about the clone mode support? I like live
> mode for the radios that support it because you get instant feedback about
> memories being good, but the async nature of that indication has always
> been pretty janky. That, and my kenwoods all just do command mode
> (driver-wise at least).
>

Honestly, I prefer the D72's clone driver, as a full read or write
operation takes <20 seconds total with it.  That said, the driver was
broken for several years due to a bug relating to VFO filtering (eventually
fixed in #1611).  While it works great now, anyone who tried to use it
during the time it was busted are likely still using the live version,
whether out of lack of trust or sheer habit.

The live version under the existing UI is ok too.  It takes a few minutes
to do the initial read, but then each edit gets instantly
applied/rejected.  My concern was mainly that the new UI greatly increases
the amount of time to sync the changes back for the live driver, which some
people might not be happy about :)  However, if you can add the ability to
just sync the dirty memories edited during the same session the radio was
read during, that'd probably make it a non-issue.

That said, regardless of the impact to this specific radio/driver, the new
UI still seems like a positive thing overall.

Cheers,
James VE7JWK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20191210/879ca050/attachment-0001.html