[chirp_devel] Comments on a UI rewrite

[James King]

Hi Dan,


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20191207/45dd725c/attachment-0001.html