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@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@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers