ChirpNextBuild » History » Revision 3

« Previous | Revision 3/30 (diff) | Next »
Dan Smith, 12/16/2022 04:07 PM

About CHIRP-next

This page explains the chirp-next build, why it is necessary, what to expect, and how you can help.

Why is this necessary?

When CHIRP started in 2008, it was based on two core pieces of modern-at-the-time software, Python 2.x (the language) and PyGTK (the GUI toolkit). Since then, the Python development team defined Python 3.0, which is an evolution of the language, but with many incompatible changes, specifically in the areas that affect CHIRP. Further, the developers of PyGTK decided to mothball the project and not ever move to support Python 3. This left CHIRP in a tough spot, as moving to Python 3 not only required significant changes to almost every radio driver (of which there are about 350) and basically a complete re-write of the GUI at the same time. There are various shims and hacks for temporary compatibility that we could have (and in some cases, did) explore, but the end result was the same: something had to change.

Mac and Linux users are likely painfully aware of the increasing difficulty in running CHIRP that has been creeping up for the last few years. Python 2.7 was officially End-of-Lifed in 2020, and many Linux distros dropped support around then. Apple held on a little longer, but has removed Python 2.7 from MacOS now. Windows' users have been largely unaffected directly by the deprecation issue, but developers have an increasingly shrinking set of platforms they can use to continue CHIRP development.

How you can help

Perhaps the biggest hurdle to this transition has been the radio drivers. CHIRP supports hundreds of unique radio models, and in many cases, those were developed with borrowed radios, or radios that a developer owned at the time, but no longer has. Rewriting those drivers and testing them with real hardware is an enormous task for an all-volunteer project like this. To get to where we are today, we had to find and test as many real radios as possible. Developers borrowed, bought on eBay (yes, really), and dug out of the woodwork as many as possible, but there is (and likely will be) a long tail of models that we're looking for.

Re-writing the GUI also brings many challenges, as this is largely maintained by one person in the development team. A re-write gives us an opportunity simplify, eliminate complex features that are rarely used, and also make CHIRP behave a little better on each of the platforms. Instead of being "A Linux program that runs on Windows," we have also used this opportunity to try to make it feel more like a native app on each of the platforms we support.

We now need to engage the larger community of users, power-users, and enthusiasts to try to close the gap on radio testing, GUI testing, etc.

Test obscure radio models

If you have one of the radios on the list of un-tested models, please consider giving it a try and filing a bug. Even if it works fine, please let us know so we can mark it down. If it doesn't, it would be great if you would be willing to test some changes to help us get it fixed. If it's an older radio, consider donating it to a developer (this is the most helpful thing you can do).

Further test well-supported models

We attempted to "smoke test" converted drivers for the new platform, but it's possible that bugs still lurk in strange configurations. Even if you only have radios that have already been tested, we welcome more comprehensive tests. Note: if you find a bug, it would be helpful if you can test the same issue on the legacy build and include in your bug report whether or not it's broken there, or only in the new build.

Updated by Dan Smith over 1 year ago · 3 revisions