[chirp_devel] Py3 live mode - understanding the intent

[Martin Cooper]

Hi Dan,

Thanks for the explanation.

The ability to persist settings could be solved by using a "generic JSON"
driver instead of the "generic CSV" driver. A top-level structure such as {
"memories": [ ... ], "settings": [ ... ] } would do the trick, saved using
a FileBackedRadio, and base-64-encoding the JSON to deter fiddling with the
file.

It seems to me that there's a larger problem, though, with using a generic
format for persistence for particular radios. That's the inability to
associate the appropriate features with the data on the way in (i.e. on
loading from a file). Without some association with the "real" driver,
values such as memory_bounds, has_bank, etc., are unknown. (For example, if
I download from my IC-910H, which has a lower bound of 1, then store to
JSON, then load that file, the resultant table shows a lower bound of 0,
because it doesn't know any better.)

To solve that, I think we'd need to adopt a persistence format (JSON or
whatever) in the live-mode drivers, complete with VENDOR and MODEL fields
for each radio. The storage format could still be generic, just with enough
data to properly reconstitute it. That said, I'm not sure that this is such
a great idea in the first place.

By the way, while playing around with this, I found a buglet in
chirp_common.is_version_newer(). It doesn't account for a trailing 'dev' in
the version number, as we have today, so it logs two errors when comparing
'0.3.0dev', and then compares (0,) with (0,). I'll file a ticket.

Regarding your comment on Windows and GUI threads, yes, and in fact some
GUI (and TUI) frameworks have the same restriction on all platforms, so
it's good to follow this practice in any case.

Martin.
KD6YAM

On Mon, Apr 25, 2022 at 6:04 PM Dan Smith via chirp_devel <
chirp_devel at intrepid.danplanet.com> wrote:

> > Before I dive in and look at making changes, it would be helpful to
> understand the thinking behind the approach, and the intent of how it
> should work, particularly in regard to the points mentioned above, but also
> in any other related regard. I do have a local change for writing only
> changed memories, but I'd like to have the big picture before going any
> further.
>
> It was a bit of an experiment, an attempt to rethink the split and maybe
> close the gap on the behavioral differences. I was thinking these would
> effectively use csv as their backing store for saving (which right now is
> an export, yet another step those users).  As you note, keeping track of
> the memories we need to upload in a single session would be easy, but
> unless we persist that, we'll have to (slowly) upload the whole thing if we
> have closed and re-opened it. Radio settings are another thing that we
> couldn't perisist (in CSV at least) and which would have to behave
> differently if the tab was closed and the serial link to the radio lost.
>
> Windows also has specific requirements about how all the GUI updates have
> to happen from the same thread, which is one reason for current radiothread
> stuff in the main branch, and minimizing what gets done where (i.e. a
> single simulated clone) helps address that problem.
>
> All that said, I wasn't overly thrilled with the experiment, because while
> it seems to be simpler and more uniform from a UX perspective, the above
> issues, of course, make it not as straightforward. So I dunno what the best
> plan is, TBH.
>
> --Dan
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20220428/964fb436/attachment-0001.html