The current UI has this gross and complex threading system to delegate all the interactions with the radio to a worker thread. It does this for all drivers, purely in order to support the live-mode radios. This rewrite doesn't do that, and is massively simpler and more predictable while editing as a result. Right now if you "download" from a live-mode radio, it makes it look like a clone and pulls the entire radio contents down in one pass. Internally it stores that as a CSV file, and then behaves exactly like a clone-mode radio. I will have to implement some sort of way to indicate which memories failed during an upload, and settings will have to behave differently from memory edits, as they won't be stored. However, I think that the users will probably prefer everything to behave the same.
Anyone have comments on this live-mode change? I've been playing with it with a D700 (which is live-mode) and so far I think I'm on board.
I tried the new UI out on my TH-D72A on MacOS 10.14.6 (Mojave). While I somewhat miss the lazy loading of memories that the old UI currently does, the native look definitely looks much nicer overall!
A few takeaways I had:
1. I can't speak to other radios, but on this particular model writing out all 1000 memories is achingly slow in live mode, at least as compared to clone mode. If upload-after-edit is to be the new pattern for this style of driver, you might want to consider flagging individual memories as dirty upon edit and only sync those instead of writing out the entire set.
2. Continuing to call them "live mode" drivers might be a bit of a misnomer. Perhaps these should be renamed "command mode" or something similar in order to highlight the change in behaviour.
3. The MacOS .app bundle looks quite different under the new UI. Instead of having the individual CHIRP .py files loaded at startup from ./Contents/Resources/chirp/chirp/ , they all appear to be pre-compiled into a single mach-o binary at ./Contents/MacOS/chirpwx now instead. Assuming I'm not off base here, I'm wondering if that'll have any implications on the ability to re-implement the Load Module functionality the current UI has in order to load new/test drivers at runtime?
The timing of this thread was a bit serendipitous for me. I was recently looking into what it would take to add UI support for some additional non-memory, tabular-oriented data into an existing driver, and came away a bit discouraged after seeing what went into the existing memory/dstar editors. By comparison, your new ChirpMemEdit class looks much more straightforward to build upon. I'm still fairly new to Python, but I'd also be willing to try and help with some of the driver conversion work you mentioned previously, at the very least for the ones I have radios to test against.
Thanks for all your effort on this and the py3 work in general!
James VE7JWK