I think this is a great idea! I've been putting off making a few changes because I would have to install and learn mercurial and everything I do is in git. Also, what you said about running the newest programming languages is true.
However, I urge you to think even further!
I've been thinking about Chirp running on a web-based platform! You could use GDocs for most of the interface. Combine that with Javascript and Electron (electronjs.org) and now you have an app that would run on all platforms (Linux, Mac, Win) with no additional work. More and more apps are moving to this model. For example, Slack and Visual Studio Code are Electron apps. The WebUSB API makes it easy to talk to and run USB dongles with Javascript.
-David, N9KT
On Fri, Jun 8, 2018 at 3:06 PM chirp_devel-request@intrepid.danplanet.com wrote:
Send chirp_devel mailing list submissions to chirp_devel@intrepid.danplanet.com
To subscribe or unsubscribe via the World Wide Web, visit http://intrepid.danplanet.com/mailman/listinfo/chirp_devel or, via email, send a message with subject or body 'help' to chirp_devel-request@intrepid.danplanet.com
You can reach the person managing the list at chirp_devel-owner@intrepid.danplanet.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of chirp_devel digest..."
Today's Topics:
- Modernizing (Derek Chauran)
Message: 1 Date: Fri, 8 Jun 2018 08:44:20 +0000 From: Derek Chauran af7ux@outlook.com Subject: [chirp_devel] Modernizing To: "chirp_devel@intrepid.danplanet.com" chirp_devel@intrepid.danplanet.com Message-ID: < MWHPR13MB0896ACF6D5270D897D27668EE1670@MWHPR13MB0896.namprd13.prod.outlook.com
Content-Type: text/plain; charset="utf-8"
I have been thinking about this for a while, but Terrence's API/module & Dan's feedback have spurred me to put it out there.
What are people's thoughts on starting to port Chirp to Python 3/GTK+, and moving to GitHub? Both are things that I think would help encourage more people to develop for Chirp. Most young and enthusiastic developers don't want to work with old versions of a programming language. As to the GitHub question, while it may seem like a small thing, I also believe that comfort level with the development process is important to attract developers. GitHub has massive adoption, and most developers I know have some degree of comfort working in git environments, whereas I get blank stares when I mention mercurial.
There are a few discussion points that jump out at me. I'll throw them out there to start the discussion, but I know there are many other points to be made.
- No XP support past Python 3.5. I think this is actually a good
thing. I have never used XP for anything HAM radio related and it has not held me back. As technology enthusiasts, I tihnk it's silly that many hams still client to an old, unsupported and insecure OS. I have old EF Johnson land mobile radios that i can program from Windows 10 using DOSBox. Given that Chirp is a major part of the amateur radio world, deciding to no longer support an OS that the maker doesn't even support would be a factor in getting people to upgrade. 2. With Python 3, we get GTK3+. GTK+ has many enhancements that will help with some of the kunkiness inherent in the version of GTK that Chirp is built agianst. (see e.g. GIMP for windows). Of course, if Terrence's API idea pans out, then there are many other GUI options for Python 3 (PyQT, Kivy, Tkinter, etc...) 3. Git is too complex - while this can be true, when it comes to developing on GitHub, there are established patterns and simple commands to accomplish most tasks. This complexity also comes with flexibility. If I am working on a major change in git (say, upgrading from Python 2.7 to 3.6), but I run across a small bug in the production code that I want to fix, git makes it easy to put aside my other changes and fix the quick bug. During my daily workflow at work, I often switch between several branches in a repo, wiith a small set of commands. There are something like 5 commands that I use on a day to day basis with git. (git pull, git push, git checkout, git commit). Conversely, I find the patchbomb process to be a bit convoluted vs pull requests. Of course, there is also a mercurial plugin that allows mercurial users to work against GitHub repos: https://bitbucket.org/durin42/hg-git/overview [ https://d301sr5gafysq2.cloudfront.net/a6f25d658c68/img/repo-avatars/default.... ]https://bitbucket.org/durin42/hg-git/overview
durin42 / hg-git ? Bitbucket<https://bitbucket.org/durin42/hg-git/overview
This is the Hg-Git plugin for Mercurial, adding the ability to push and pull to/from a Git server repository from Hg. This means you can collaborate on Git based projects from Hg, or use a Git server as a collaboration point for a team with developers using both Git and Hg. The Hg-Git plugin can ... bitbucket.org
- Git is destructive - This is not really true. In fact, the opposite
is true. When you roll back a commit in HG, that commit is gone. In GIT, that commit is still available via the reflog for 30 days. The main repo will be controlled with gated checkins anyhow. 5. Github comes with its own documentation/hosting system with native support for markdown. 6. Python itself is hosted on GitHub. 7. GitHub makes it easy to share branches, so we can have multiple people collaborate on large projects (e.g. upgrading Python). 8. Time - moving to GitHub is fairly straightforward. They provide examples of exporting from HG into git. That said, unless Dan wants to (temporarily) hand over control of the repo, it's his time, not mine so I cannot speak for him there. Once that move is complete, again the python work can be staged in a separate brach and worked on as time permits while being set aside for other features that need attention in mainline.
Anyhow, I'd love to hear what other people's thoughts are on this. I don't want to go down a path that will be outright rejected ?
Thanks, Derek