[chirp_devel] Comments on a UI rewrite

Sat Dec 7 08:06:03 PST 2019

 TLDR: _Go for it Dan! We got your back._
Regarding feature parity and fragmentation, also strongly agree that this is a painful, but necessary, short-term thing. If we all pitch in, we'll get through it.

Regarding OS support:I know there are lots of opinions on both sides, but I see it (probably skewed as a Production Engineer/DevOps in my day job who has been supporting various legacy applications for many years) as fairly simple: Chirp cannot be all things, to all people, all the time. A line on supported OSes must be drawn to limit the scope and incredible complexity, in order to allow it to proceed into the future.It will become increasingly difficult to support software on top of OSes, which themselves are abandoned, especially as underlying software packages and dependencies have moved on. To continue supporting this would likely mean all sorts of unsavory acrobatics and ugly hacks in Chirp.I think it's reasonable to set this line to be currently supported OSes, e.g. OSX High Sierra+, Windows 7+, etc.In fact, Windows 7 is reaching end of life in a matter of weeks! (It seems reasonable to continue supporting it for near future, as it has a big enough base.)Nothing stops folks from continuing use of older versions of Chirp on existing radios, but for new feature and new driver support, they will need to use a modern (in a very loose sense of the word) OS.Call it Chirp 2 or 3 or whatever ;)On a side note, Derek mentioned something interesting: usage stats. Does chirp have install/usage telemetry? I.e. can you actually see where and how the software is getting used, in the real world? Else - not having seen any real data myself, and pure speculation - I would imagine you have a very small, but vocal number of XP, etc users who want you to continue supporting them through the apocalypse.
Regarding contribution on the driver migrations, I haven't been actively contributing in a long time, but I think a move to modernize/revamp Chirp might spur me on to revisit. (I still have several Yaesu radios that I can develop and test against). Is there a documented guide/wiki/etc on how to do this migration, or just pointing to examples of stuff already been migrated? (At least a conceptual outline may be a useful starting point for figuring out how to attack the migration of a given driver.)
This might be a good time to rekindle an old topic I have brought up before, as I saw another recent thread mentioning Github as well.I know there are good reasons for and against migrating to github, but I wonder if now would be a good time to reconsider, especially if it's a "major version bump" sort of move, e.g. Chirp 2 will be on github (issue/project tracking, wiki, pull requests/code reviews/feedback, release/version/tagging management, ci/cd build/test integration, etc.) I think there are multiple intangible workflow and ecosystem benefits from migrating the project (or at least a new incantation of such) to github. Example: in many aspects, I think it may be easier for you to delegate review/management code maintenance tasks to a team of trusted folks/reviewers/etc, as I'm thinking the depth and breadth of such a herculean task you are outlining here can only be accomplished with the coordinated effort of a community. I can't imagine you trying to do all/most of the lifting on your own. Here is where I think the current, dare I say fragmented, development workflow - mercurial, patchbombs, email list discussions/reviews/etc - these won't scale or provide the same efficiency as some more modern development workflows - whether it's github/gitlab/bitbucket/whatever - any of these provide a very rich set of features with deep integration. But again, I understand that Chirp is your child which you and a few others have put years of TLC and gardening into - myself and the entire community is very grateful for this  - so it's ultimately your choice on what level of control you turn over to a delegated community.
-JensAF5MI

    On Friday, December 6, 2019, 04:15:57 PM CST, Derek Chauran via chirp_devel <chirp_devel at intrepid.danplanet.com> wrote:  

 I poked around in this build a bit, will try to look further this weekend.
As a Windows user, I absolutely love the idea of getting a native UI on windows. Things like tab order, copy/paste, etc.. in the grid controls really throw me off with the current implementation. This UI definitely feels better, but still has some weird behavior around tab order and using the keyboard (e.g. if I type in part of a tone, it selects the tone in the list but does not preserve when I tab out). I am not sure which issues are fundamental to wx vs the fact that this is essentially a v0.
Feature parity, do you have a general idea of what would drop? I think moving to python 3 and a simpler build process will make development easier, so the feature loss might be short-term.
Windows XP support, I would suggest perhaps blasting this on the main and download pages in bright red flashing all caps, starting ASAP, providing an end of life date, and seeing how much backlash there really is. Do you have stats on Windows versions? I have not seen many people in the ham community still using XP. Most have been convinced to upgrade. XP is also horribly out of date and insecure, and I think CHIRP dropping XP support would likely convince a lingering handful of users to upgrade. At the end of the day, you can't please everyone.

From: chirp_devel-bounces at intrepid.danplanet.com <chirp_devel-bounces at intrepid.danplanet.com> on behalf of Dan Smith via chirp_devel <chirp_devel at intrepid.danplanet.com>
Sent: Friday, December 6, 2019 9:45 AM
To: chirp-devel <chirp_devel at 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.chirp.danplanet.com%2Ftemp%2Fwindows.png&amp;data=02%7C01%7C%7C435a2dafe8cb4ba1536f08d77a741615%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637112511316321955&amp;sdata=FQ7neofYp52AYEZZqJZjwBINgbePln5Ud%2BVhhFyPu8E%3D&amp;reserved=0
  MacOS: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.chirp.danplanet.com%2Ftemp%2Fmacos.png&amp;data=02%7C01%7C%7C435a2dafe8cb4ba1536f08d77a741615%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637112511316331966&amp;sdata=e17DC4zaJ2MLUm%2B%2BZtZpM6w87b1K1Mx7AKMKrmeMIyg%3D&amp;reserved=0
  Linux: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.chirp.danplanet.com%2Ftemp%2Fwindows.png&amp;data=02%7C01%7C%7C435a2dafe8cb4ba1536f08d77a741615%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637112511316331966&amp;sdata=93L7FRksfRFAXhJNjkE6D4VdSkOH%2FFcisqms%2F%2Bq24Tk%3D&amp;reserved=0

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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.chirp.danplanet.com%2Ftemp%2F&amp;data=02%7C01%7C%7C435a2dafe8cb4ba1536f08d77a741615%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637112511316331966&amp;sdata=sxL6wonVb1Cy3RBAiWTFeDildEEw%2FMBI0xmg1IHFP4s%3D&amp;reserved=0

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 at intrepid.danplanet.com
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintrepid.danplanet.com%2Fmailman%2Flistinfo%2Fchirp_devel&amp;data=02%7C01%7C%7C435a2dafe8cb4ba1536f08d77a741615%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637112511316331966&amp;sdata=8qMzi8xdxhH0I86aJ7xwlrkfxjWXag0skliiZVA2aoE%3D&amp;reserved=0
Developer docs: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fchirp.danplanet.com%2Fprojects%2Fchirp%2Fwiki%2FDevelopers&amp;data=02%7C01%7C%7C435a2dafe8cb4ba1536f08d77a741615%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637112511316331966&amp;sdata=2jeVv8LCog17Nh9Tr3TSXjKUQQ4qHOKCqntY33qPhOA%3D&amp;reserved=0
_______________________________________________
chirp_devel mailing list
chirp_devel at intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20191207/b79a5ac7/attachment-0001.html 