[chirp_devel] Py3 live mode - understanding the intent
This is really directed towards Dan, since I suspect he's the only one with answers. :-)
In the py3 branch, it seems that the intent for live mode radios is to change the behaviour so that they act more like clone mode. That is, instead of changes being sent to the radio as soon as they're made, as with today's Chirp, nothing is sent to the radio until an Upload is done. I presume this was done to make the two modes appear more consistent. (It's confusing to existing users who expect instant changes, though, and will require clear documentation.)
As part of the implementation, a LiveAdapter class is used, and that is a subclass of the Generic CSV driver. I'm guessing is that this is intended to enable the saving and loading of "images" for live mode radios, using CSV files as the file backing. After downloading from a live mode radio, saving does work, and produces a CSV file, but with a file extension of "img" rather than "csv". Due to that file extension, however, loading does _not_ work, because the image type detection code does not look for CSV-typed data.
Also, immediately after a Download, the tab in the GUI shows a ".img" filename, and shows it as edited. It's unclear as to whether this is intended (because no file has been saved) or not (because no changes have actually been made to the memories that were just downloaded).
Finally (for now), when running an Upload, all memories are written to the radio, regardless of whether or not they have been changed. This can be slow, since all memories in all banks are written. If I Download from the radio, change one memory, and then Upload to the radio, because of the way live mode radios work, it seems like it would make more sense to upload only the memory that has changed. This may get more complicated when dealing with "images" loaded from a file, though - or maybe not, since memories are also being read as they are being written.
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.
Thanks,
Martin. KD6YAM
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
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
participants (2)
-
Dan Smith -
Martin Cooper