[chirp_devel] Comments on a UI rewrite

[Dan Smith]

> The link for Linux is a copy of the Windows example. Easy enough to
> substitute "linux" for "windows" to retrieve it.

Oops, thanks :)

> I had been using XP to do my serial port captures. Mainly because that
> was the OS installed on the laptop I was using and it was 32-bit so it
> would work with Portmon. Once I have serial port captures, I move them
> over to a Windows 7 Home Premium 64-bit desktop (that Portmon won't
> work with) to continue.
> 
> That being said, I recently purchased a really cheap HP thin client
> and installed Windows 7 Pro 32-bit on it specifically to be able to
> run CHIRP and Portmon. The thin client even has a hardware serial port
> should I need it.
> 
> So at least I can say I am at the point now where dropping Windows XP
> support should not affect me.

Yeah, I still have things on XP (some related and some not related to chirp), but it's becoming less and less useful.

> I downloaded the Windows build. My Windows 7 desktop computer must
> already have the VS2015 runtime because the test CHIRP build loaded up
> fine.

Cool, yeah, anything else that uses that runtime would have put it on there, so cool.

> The memory rows are numbered incorrectly and have more memory rows
> than the radio supports. I assume that this is not what we are looking
> for at this stage of the game?

I think for the things I've been looking at, it's right, but yeah, lots of little one-off things like that to fix of course...

> I downloaded the Linux build. I had to install the python-future
> package to run it. When it comes up it doesn't look like the linux
> example. In Windows there only 2 options on the menu bar: File, Radio
> and Help. In the example the same menu bar options are show. On my
> linux computer the menu options are the same as a normal CHIRP build:
> File, Edit, View, Radio and Help (example attached). The Loc numbers
> aren't centered in the column or bold. There are also not grid lines.
> It is almost like some kind of hybrid has been loaded.

I imagine you ran "chirpw" like normal, which will boot the old interface. Look for chirpwx.py right next to it and it should load it up. You will need to "python3 -mpip install wxPython" first, at least. Sorry I didn't mention that. But, now you see that the two UIs can co-exist for the time being at least.

> I currently have both the latest build and the test build showing on
> my Windows 7 Home computer. For the features that are available to
> compare on both, I think I like the test build better. I really like
> the grid lines. The bold column headings look nice. The tabs across
> the top of the memory editor have a better look. Visually, I don't
> have anything to complain about.

Okay. It definitely looks 1000% better on a Mac, since it draws natively, and I think the Windows one looks a lot better than the old interface. I think it's faster with lots of memories on all platforms too, partially because of native widgeting, but also because the re-write depends less on rendering all the data in the event loop and refreshing it from the radio obsessively. I don't plan to implement the memory range selector thingy as a result, as that was always purely to limit how much data was being refreshed at once.

> The ability to past data from an external application is a welcome change.

That's an side effect of the fact that I haven't implemented copy-and-paste of memories yet, so the default "paste text into a cell" behavior still works :) But yeah, that's one giant wart I'd love to have a chance to do less stupidly in a re-write.

One other thing I forgot to mention about this:

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.

Thanks Jim!

--Dan