Dan,

On the "thoughts in general" CTA...

Did you consider PyQT as an alternative? Riverbank Computing has done a fantastic job maintaining python wrappers for Qt and likewise it also generates native windows for each platform. There is  a build tool called PyQt Deploy that helps package up the app for various platforms (I have not used it however)

The python documentation for pyqt is pretty lacking IMHO but referencing the official qt.io website makes developing a breeze as the PyQt wrapper is almost identical every time (some variations exist when you run into pointers to pointers and such).

Either way, moving off pygtk is a good move.

Tony
From: chirp_devel-bounces@intrepid.danplanet.com <chirp_devel-bounces@intrepid.danplanet.com> on behalf of Dan Smith via chirp_devel <chirp_devel@intrepid.danplanet.com>
Sent: Friday, December 6, 2019 11:45:15 AM
To: chirp-devel <chirp_devel@intrepid.danplanet.com>
Subject: [chirp_devel] Comments on a UI rewrite
 
Hi all,

Long email, skip to the 'tl;dr' to bypass the history and complaining.

As you probably know, there is looming apocalypse on the horizon in the form of python2 deprecation. Over the last year, I've done some work on making the tree compatible with python3. That work is in the "py3" branch of the repository. The drivers require a lot of attention, and only some of them have been converted there. The bigger concern is and always has been the UI. We use pygtk, which is not getting forward ported to python3. The py3 branch has changes inside to use the pygobject compatibility layer for pygtk, which works, but I'm not very happy with it (at all).

I've historically been rather unexcited about re-writing the UI, especially in response to pygtk support being dropped, and to linux distros dropping python2 entirely. The macOS 32-bit deprecation also likely means that we have to make a move there at some point, and py2app seems to be abandonware. Something like 94% of the users are on Windows, which is not going to be a problem in this area for quite a while. I'm not a Windows user, but given how many of the users are, the stability of that platform further deflates my excitement about a re-write. However, py2exe seems to also be abandoned.

However, I've been mulling what a UI rewrite would look like for some time and I started tinkering with wxPython in the evenings over the last week. Specifically, I wanted to see/prove if some of the more complex elements of the UI (i.e. the memory editor) would be reasonably doable. One major benefit of wxPython is that it generates native UI widgets on each of the platforms. That means Windows users get a more native-feeling app, as do MacOS users, and Linux still gets native GTK.

Here are examples of:

  Windows: https://trac.chirp.danplanet.com/temp/windows.png
  MacOS: https://trac.chirp.danplanet.com/temp/macos.png
  Linux: https://trac.chirp.danplanet.com/temp/windows.png

There are some definite drawbacks to going in this direction:

1. Fragmentation. For some period of time, we'll have to be generating duplicate builds and there will be confusion in the community about which one to use, which one bugs are being reported for, etc.
2. Parity. It's going to take a lot of work to fully reimplement the current UI, and in all likelihood, some of the features won't get pulled into the new version. The current UI does a lot of things and I don't know what all is really useful or used by people. However, it's also a chance to start afresh and unify/polish things.
3. OS support. Right now our binary builds work on Windows XP, and some really old versions of MacOS. I'm not so worried about the latter as Mac people seem to *love* to upgrade their OS on the day of the release, bugs be damned. Right now, I think we can support >= High Sierra, which is three old and from 2017. However, I think we'd probably end up breaking support for anything older than Windows 7, which might be rather unpopular.
4. Drivers. This works on Python2, but I'd be generating builds with Python3 only. That means people need to chip in and help convert the problematic drivers to work with Python3. There are lots of examples of doing this in the tree, so hopefully anyone just willing to do some grunt work can help with this.

[tl;dr]

Basically, I'm looking for some input from people on whether or not we should pursue this. As much as I hate to rewrite something that works perfectly fine, I am concerned about the sustainability of the build process for the old stuff, especially on MacOS. I've been pleasantly surprised with how wxPython works, and it seems to be a lot simpler than GTK/pygobject in a lot of ways. The build is *definitely* majorly easier with these. GTK requires a stupid amount of extra stuff to work, and so generating a unified OS-specific build for it is a major pain.

I'd appreciate it if people could pull the relevant test build from here and load it up to see what they think:

https://trac.chirp.danplanet.com/temp/

Note that the Windows build will likely only run on Windows 10, unless you have the VS2015 runtime on your system already. It also starts slow because it's packed into a single executable (that'll be better on a real build). The MacOS build should run on High Sierra or later. There are definitely some weird visual things, like dialog boxes with weird shapes, but that's just because it's all thrown together. These builds are all running python3 with no GTK.

You can see the code for this in the linux tarball. It's all in chirp/wxui, nothing else is changed in the regular code (yet).

So, let me know what you think. Do windows-y people hate the way this looks/behaves for some reason? Is the spreadsheet-like interface less good than what we have now? Anyone have other concerns than what I mentioned above? Thoughts in general?

If people want to move forward, I can push this into the repo. Let me know what you think.

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