[chirp_devel] Comments on a UI rewrite

[Dan Smith]

Hi James,

> 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!

Cool, thanks for that feedback.

> 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.

For a single editing session that would work, yeah.

Have you set the baud rate up? At 57600 (the max my D700 will do) 200 memories come across pretty quick. The D710 can do 115200, so I imagine the D72 can as well, which should be fairly snappy.

> 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.

Do any of them say "live" in the name? If so, we'll want to do that yeah.

> 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?

No, it should be fine. This is more in keeping with how the win32 binary worked, and module loading was fine.

> 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.

Yep, it's way simpler. It does less, of course, but it's definitely simpler.

--Dan