[chirp_devel] chirp_devel Digest, Vol 86, Issue 5

[David Spoelstra]

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 at intrepid.danplanet.com>
wrote:

> Send chirp_devel mailing list submissions to
>         chirp_devel at 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 at intrepid.danplanet.com
>
> You can reach the person managing the list at
>         chirp_devel-owner at 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:
>
>    1. Modernizing (Derek Chauran)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 8 Jun 2018 08:44:20 +0000
> From: Derek Chauran <af7ux at outlook.com>
> Subject: [chirp_devel] Modernizing
> To: "chirp_devel at intrepid.danplanet.com"
>         <chirp_devel at intrepid.danplanet.com>
> Message-ID:
>         <
> MWHPR13MB0896ACF6D5270D897D27668EE1670 at 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.
>
>   1.  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.png
> ]<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
>
>
>   4.  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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20180608/22b8260e/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
>
>
> End of chirp_devel Digest, Vol 86, Issue 5
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20180608/354d868b/attachment-0001.html