[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
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
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).
I did indirectly because I've used pyqt before. It's okay, and does address the concern of stability, likely future proofness, etc. However, it's more complex for sure, and I recall it not feeling super Pythonic or intuitive. I also don't think QT generates *actual* native widgets, just that it draws widgets on each platform that *look* native. We've long been beat up by the blind community for not having native widgets on Windows, which causes their screen readers to see a blank window. This is not a primary goal here, but it certainly seems like a nice thing, especially since even Windows' look and feel has changed over time.
I can say that the wx-based MacOS app is worlds better than GTK3 using Cocoa drawing and emulating the native Mac widgets.
--Dan
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@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 9:45 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.chirp... MacOS: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.chirp... Linux: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.chirp...
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...
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 https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintrepid.da... Developer docs: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fchirp.danpl...
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@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@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 9:45 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.chirp... MacOS: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.chirp... Linux: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.chirp...
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...
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 https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintrepid.da... Developer docs: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fchirp.danpl... _______________________________________________ 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
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.
Obviously we can't support everything forever, and nobody would suggest that. WinXP is similar enough to modern times that supporting it has, thus far, not been difficult (at all), and runs on a lot of old hardware. It's not that I don't think we should ever move the minimum version forward, it's just that I see no reason to do it until or unless there is a good reason to do so.
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.
Yes, I have some stats. However, they don't count users that aren't connected at the time of use. Given how it's difficult to even get a modern browser on XP and navigate the https world, I suspect most of the people using it are doing so by downloading chirp elsewhere and using it on XP offline. And, of course, not everyone allows the reporting.
A quick query out of the stats show that in 2019, 3% of all windows users were on XP. That was 4% in 2018 and 6% in 2017. All versions of MacOS constituted about twice the raw number of WinXP reports in 2019. Clearly a downward trend indicating that the number of people affected is shrinking, as MacOS users are the smallest fraction. MacOS and Linux users (combined) constitute about 10% of the total, so choosing to keep 2% of users on XP instead of the 10% on Mac/Linux seems like an obviously bad idea.
Either way, dropping WinXP was lowest on my list of concerns (the list in the top of this thread wasn't really sorted), and the stats certainly support that not being as import
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.)
No, but the tests are a good place to start. Fix the syntax issues for py3 so the tests will import the driver, and then iterate until it passes. And, of course, looking at the diffs of conversions of other drivers. We could start a wiki page with issues and resolutions, but I haven't done that yet.
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 do not want to change the ui toolkit, the language, and the entire process all at once, no. The thing I value the most is the long-time contributors that have done most of the work here, many of which are not professional developers. I understand the desire to move towards a github workflow, but it's just not that important to me. I (and other devs here) have tooling and processes setup for how things are now. The python3 thing is an acute problem needing solving -- the process one is not at the moment.
--Dan
Hi Dan,
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
The link for Linux is a copy of the Windows example. Easy enough to substitute "linux" for "windows" to retrieve it.
There are some definite drawbacks to going in this direction:
- 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.
- 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.
- 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.
- 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.
I had been using XP to do my serial port captures. Mainly because that was the OS installed on the laptop I was using and it was 32-bit so it would work with Portmon. Once I have serial port captures, I move them over to a Windows 7 Home Premium 64-bit desktop (that Portmon won't work with) to continue.
That being said, I recently purchased a really cheap HP thin client and installed Windows 7 Pro 32-bit on it specifically to be able to run CHIRP and Portmon. The thin client even has a hardware serial port should I need it.
So at least I can say I am at the point now where dropping Windows XP support should not affect me.
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.
I downloaded the Windows build. My Windows 7 desktop computer must already have the VS2015 runtime because the test CHIRP build loaded up fine.
The memory rows are numbered incorrectly and have more memory rows than the radio supports. I assume that this is not what we are looking for at this stage of the game?
I downloaded the Linux build. I had to install the python-future package to run it. When it comes up it doesn't look like the linux example. In Windows there only 2 options on the menu bar: File, Radio and Help. In the example the same menu bar options are show. On my linux computer the menu options are the same as a normal CHIRP build: File, Edit, View, Radio and Help (example attached). The Loc numbers aren't centered in the column or bold. There are also not grid lines. It is almost like some kind of hybrid has been loaded.
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?
I currently have both the latest build and the test build showing on my Windows 7 Home computer. For the features that are available to compare on both, I think I like the test build better. I really like the grid lines. The bold column headings look nice. The tabs across the top of the memory editor have a better look. Visually, I don't have anything to complain about. The ability to past data from an external application is a welcome change.
Jim KC9HI
The link for Linux is a copy of the Windows example. Easy enough to substitute "linux" for "windows" to retrieve it.
Oops, thanks :)
I had been using XP to do my serial port captures. Mainly because that was the OS installed on the laptop I was using and it was 32-bit so it would work with Portmon. Once I have serial port captures, I move them over to a Windows 7 Home Premium 64-bit desktop (that Portmon won't work with) to continue.
That being said, I recently purchased a really cheap HP thin client and installed Windows 7 Pro 32-bit on it specifically to be able to run CHIRP and Portmon. The thin client even has a hardware serial port should I need it.
So at least I can say I am at the point now where dropping Windows XP support should not affect me.
Yeah, I still have things on XP (some related and some not related to chirp), but it's becoming less and less useful.
I downloaded the Windows build. My Windows 7 desktop computer must already have the VS2015 runtime because the test CHIRP build loaded up fine.
Cool, yeah, anything else that uses that runtime would have put it on there, so cool.
The memory rows are numbered incorrectly and have more memory rows than the radio supports. I assume that this is not what we are looking for at this stage of the game?
I think for the things I've been looking at, it's right, but yeah, lots of little one-off things like that to fix of course...
I downloaded the Linux build. I had to install the python-future package to run it. When it comes up it doesn't look like the linux example. In Windows there only 2 options on the menu bar: File, Radio and Help. In the example the same menu bar options are show. On my linux computer the menu options are the same as a normal CHIRP build: File, Edit, View, Radio and Help (example attached). The Loc numbers aren't centered in the column or bold. There are also not grid lines. It is almost like some kind of hybrid has been loaded.
I imagine you ran "chirpw" like normal, which will boot the old interface. Look for chirpwx.py right next to it and it should load it up. You will need to "python3 -mpip install wxPython" first, at least. Sorry I didn't mention that. But, now you see that the two UIs can co-exist for the time being at least.
I currently have both the latest build and the test build showing on my Windows 7 Home computer. For the features that are available to compare on both, I think I like the test build better. I really like the grid lines. The bold column headings look nice. The tabs across the top of the memory editor have a better look. Visually, I don't have anything to complain about.
Okay. It definitely looks 1000% better on a Mac, since it draws natively, and I think the Windows one looks a lot better than the old interface. I think it's faster with lots of memories on all platforms too, partially because of native widgeting, but also because the re-write depends less on rendering all the data in the event loop and refreshing it from the radio obsessively. I don't plan to implement the memory range selector thingy as a result, as that was always purely to limit how much data was being refreshed at once.
The ability to past data from an external application is a welcome change.
That's an side effect of the fact that I haven't implemented copy-and-paste of memories yet, so the default "paste text into a cell" behavior still works :) But yeah, that's one giant wart I'd love to have a chance to do less stupidly in a re-write.
One other thing I forgot to mention about this:
The current UI has this gross and complex threading system to delegate all the interactions with the radio to a worker thread. It does this for all drivers, purely in order to support the live-mode radios. This rewrite doesn't do that, and is massively simpler and more predictable while editing as a result. Right now if you "download" from a live-mode radio, it makes it look like a clone and pulls the entire radio contents down in one pass. Internally it stores that as a CSV file, and then behaves exactly like a clone-mode radio. I will have to implement some sort of way to indicate which memories failed during an upload, and settings will have to behave differently from memory edits, as they won't be stored. However, I think that the users will probably prefer everything to behave the same.
Anyone have comments on this live-mode change? I've been playing with it with a D700 (which is live-mode) and so far I think I'm on board.
Thanks Jim!
--Dan
I downloaded the Linux build. I had to install the python-future package to run it. When it comes up it doesn't look like the linux example. In Windows there only 2 options on the menu bar: File, Radio and Help. In the example the same menu bar options are show. On my linux computer the menu options are the same as a normal CHIRP build: File, Edit, View, Radio and Help (example attached). The Loc numbers aren't centered in the column or bold. There are also not grid lines. It is almost like some kind of hybrid has been loaded.
I imagine you ran "chirpw" like normal, which will boot the old interface. Look for chirpwx.py right next to it and it should load it up. You will need to "python3 -mpip install wxPython" first, at least. Sorry I didn't mention that. But, now you see that the two UIs can co-exist for the time being at least.
I had to install pip3 first...
sudo apt-get install python3-pip
Then when I attempted to install wxPython I got a "ModuleNotFoundError: No module named 'setuptools'" error.
jim@jim-desktop:/media/jim/e86c7433-1ab9-44d7-a2f8-76ea78f5f498/Radio_Stuff/chirp_wx/chirp-20191206-wx$ python3 -mpip install wxPython Collecting wxPython Using cached https://files.pythonhosted.org/packages/b9/8b/31267dd6d026a082faed35ec8d9752... Complete output from command python setup.py egg_info: Traceback (most recent call last): File "<string>", line 1, in <module> ModuleNotFoundError: No module named 'setuptools'
---------------------------------------- Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-3pev7nrm/wxPython/ jim@jim-desktop:/media/jim/e86c7433-1ab9-44d7-a2f8-76ea78f5f498/Radio_Stuff/chirp_wx/chirp-20191206-wx$
Any ideas?
Jim
jim@jim-desktop:/media/jim/e86c7433-1ab9-44d7-a2f8-76ea78f5f498/Radio_Stuff/chirp_wx/chirp-20191206-wx$ python3 -mpip install wxPython Collecting wxPython Using cached https://files.pythonhosted.org/packages/b9/8b/31267dd6d026a082faed35ec8d9752... Complete output from command python setup.py egg_info: Traceback (most recent call last): File "<string>", line 1, in <module> ModuleNotFoundError: No module named 'setuptools'
Hmm, what version/distro? You can try "apt-get install python3-setuptools" although I would think you'd already have it.
You can also install the distro-provided wxPython if it has one (python3-wxgtk3.0 or 4.0).
--Dan
On Sat, Dec 7, 2019 at 9:25 AM Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
jim@jim-desktop:/media/jim/e86c7433-1ab9-44d7-a2f8-76ea78f5f498/Radio_Stuff/chirp_wx/chirp-20191206-wx$ python3 -mpip install wxPython Collecting wxPython Using cached https://files.pythonhosted.org/packages/b9/8b/31267dd6d026a082faed35ec8d9752... Complete output from command python setup.py egg_info: Traceback (most recent call last): File "<string>", line 1, in <module> ModuleNotFoundError: No module named 'setuptools'
Hmm, what version/distro? You can try "apt-get install python3-setuptools" although I would think you'd already have it.
You can also install the distro-provided wxPython if it has one (python3-wxgtk3.0 or 4.0).
--Dan
I'm running Linux Mint 19.2 which is based on Ubuntu 18.04. After googling and trying what seemed to be a million different things, I finally have it running on my linux machine.
I don't know if I can remember how I did it so I will document it here.
It took this...
sudo apt-get install python3-wxgtk4.0 python3-wxgtk-webview4.0 python3-wxgtk-media4.0
And this...
sudo python3 -m pip install pyserial
So now I am good on Windows and Linux for testing.
Jim
It took this...
sudo apt-get install python3-wxgtk4.0 python3-wxgtk-webview4.0 python3-wxgtk-media4.0
This means you're getting wxPython from the distro packages instead of pip. That's what regular linux users would be getting anyway, so not a bad way to go at all.
And this...
sudo python3 -m pip install pyserial
You should be able to install python3-serial via apt as well and have everything be distro-supplied, but this works too.
--Dan
Dan,
Anyone have comments on this live-mode change? I've been playing with it with a D700 (which is live-mode) and so far I think I'm on board.
I dug out my Kenwood TH-F6a and charged it. It is the only live-mode radio that I have. When I try to download from it stops with this message:
Error communicating with radio 'utf-8' codec can't decide byte 0x80 in position 2: invalid start byte
It works fine in live-mode with the current daily build.
Jim
I dug out my Kenwood TH-F6a and charged it. It is the only live-mode radio that I have. When I try to download from it stops with this message:
Error communicating with radio 'utf-8' codec can't decide byte 0x80 in position 2: invalid start byte
Get used to it, this is the classic "driver has something non-py3-compatible inside" message. Most of the kenwood live radios share the same set of code, so I'm surprised the F6A doesn't just work, but I'll have to go digging in there to see what it's doing differently. Glad to know you have one so you can test it :)
--Dan
Hi Dan,
The current UI has this gross and complex threading system to delegate all the interactions with the radio to a worker thread. It does this for all drivers, purely in order to support the live-mode radios. This rewrite doesn't do that, and is massively simpler and more predictable while editing as a result. Right now if you "download" from a live-mode radio, it makes it look like a clone and pulls the entire radio contents down in one pass. Internally it stores that as a CSV file, and then behaves exactly like a clone-mode radio. I will have to implement some sort of way to indicate which memories failed during an upload, and settings will have to behave differently from memory edits, as they won't be stored. However, I think that the users will probably prefer everything to behave the same.
Anyone have comments on this live-mode change? I've been playing with it with a D700 (which is live-mode) and so far I think I'm on board.
I tried the new UI out on my TH-D72A on MacOS 10.14.6 (Mojave). While I somewhat miss the lazy loading of memories that the old UI currently does, the native look definitely looks much nicer overall!
A few takeaways I had: 1. I can't speak to other radios, but on this particular model writing out all 1000 memories is achingly slow in live mode, at least as compared to clone mode. If upload-after-edit is to be the new pattern for this style of driver, you might want to consider flagging individual memories as dirty upon edit and only sync those instead of writing out the entire set. 2. Continuing to call them "live mode" drivers might be a bit of a misnomer. Perhaps these should be renamed "command mode" or something similar in order to highlight the change in behaviour. 3. The MacOS .app bundle looks quite different under the new UI. Instead of having the individual CHIRP .py files loaded at startup from ./Contents/Resources/chirp/chirp/ , they all appear to be pre-compiled into a single mach-o binary at ./Contents/MacOS/chirpwx now instead. Assuming I'm not off base here, I'm wondering if that'll have any implications on the ability to re-implement the Load Module functionality the current UI has in order to load new/test drivers at runtime?
The timing of this thread was a bit serendipitous for me. I was recently looking into what it would take to add UI support for some additional non-memory, tabular-oriented data into an existing driver, and came away a bit discouraged after seeing what went into the existing memory/dstar editors. By comparison, your new ChirpMemEdit class looks much more straightforward to build upon. I'm still fairly new to Python, but I'd also be willing to try and help with some of the driver conversion work you mentioned previously, at the very least for the ones I have radios to test against.
Thanks for all your effort on this and the py3 work in general!
James VE7JWK
Hi James,
I tried the new UI out on my TH-D72A on MacOS 10.14.6 (Mojave). While I somewhat miss the lazy loading of memories that the old UI currently does, the native look definitely looks much nicer overall!
Cool, thanks for that feedback.
A few takeaways I had:
- I can't speak to other radios, but on this particular model writing out all 1000 memories is achingly slow in live mode, at least as compared to clone mode. If upload-after-edit is to be the new pattern for this style of driver, you might want to consider flagging individual memories as dirty upon edit and only sync those instead of writing out the entire set.
For a single editing session that would work, yeah.
Have you set the baud rate up? At 57600 (the max my D700 will do) 200 memories come across pretty quick. The D710 can do 115200, so I imagine the D72 can as well, which should be fairly snappy.
- Continuing to call them "live mode" drivers might be a bit of a misnomer. Perhaps these should be renamed "command mode" or something similar in order to highlight the change in behaviour.
Do any of them say "live" in the name? If so, we'll want to do that yeah.
- The MacOS .app bundle looks quite different under the new UI. Instead of having the individual CHIRP .py files loaded at startup from ./Contents/Resources/chirp/chirp/ , they all appear to be pre-compiled into a single mach-o binary at ./Contents/MacOS/chirpwx now instead. Assuming I'm not off base here, I'm wondering if that'll have any implications on the ability to re-implement the Load Module functionality the current UI has in order to load new/test drivers at runtime?
No, it should be fine. This is more in keeping with how the win32 binary worked, and module loading was fine.
The timing of this thread was a bit serendipitous for me. I was recently looking into what it would take to add UI support for some additional non-memory, tabular-oriented data into an existing driver, and came away a bit discouraged after seeing what went into the existing memory/dstar editors. By comparison, your new ChirpMemEdit class looks much more straightforward to build upon. I'm still fairly new to Python, but I'd also be willing to try and help with some of the driver conversion work you mentioned previously, at the very least for the ones I have radios to test against.
Yep, it's way simpler. It does less, of course, but it's definitely simpler.
--Dan
Hi Dan,
On Sat, Dec 7, 2019 at 6:20 AM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
- I can't speak to other radios, but on this particular model writing
out all 1000 memories is achingly slow in live mode, at least as compared to clone mode. If upload-after-edit is to be the new pattern for this style of driver, you might want to consider flagging individual memories as dirty upon edit and only sync those instead of writing out the entire set.
For a single editing session that would work, yeah.
Have you set the baud rate up? At 57600 (the max my D700 will do) 200 memories come across pretty quick. The D710 can do 115200, so I imagine the D72 can as well, which should be fairly snappy.
Unless I'm missing something, my tests suggest the D72 doesn't support programming at anything other than 9600. The COM Port->Baud rate option (menu 331) only has options for 2400/4800/9600, and setting anything other than 9600 there still results in CHIRP auto-detecting the baud as 9600. The live driver also tends to timeout several times during a read or write cycle, while the clone driver never does. The clone mode driver takes about 15 seconds, while the live variant can take upwards of 3-7 minutes depending on the number of timeouts.
- Continuing to call them "live mode" drivers might be a bit of a
misnomer. Perhaps these should be renamed "command mode" or something similar in order to highlight the change in behaviour.
Do any of them say "live" in the name? If so, we'll want to do that yeah.
Yes, it looks like there's a few Kenwood ones named in the UI like that, and a bunch of internal references in the drivers for both Kenwood and Icom radio.
Cheers, James VE7JWK
Unless I'm missing something, my tests suggest the D72 doesn't support programming at anything other than 9600. The COM Port->Baud rate option (menu 331) only has options for 2400/4800/9600, and setting anything other than 9600 there still results in CHIRP auto-detecting the baud as 9600.
This is the APRS/TNC baud rate, not the one for the PC, AFAIK, so it's unrelated. Since the D72 uses a USB port for the PC connectivity, it's possible that it will just speak to us in whatever rate we try first, which might mean we're currently auto-detecting something slow. I'll try to get my hands on a D72 soon and see if I can poke around a bit.
I can't imagine that the D700 from yesteryear can do 57600 and a modern HT like the D72 is limited to 1980s baud rates :)
--Dan
On Mon, Dec 9, 2019 at 2:23 PM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Unless I'm missing something, my tests suggest the D72 doesn't support
programming at anything other than 9600. The COM Port->Baud rate option (menu 331) only has options for 2400/4800/9600, and setting anything other than 9600 there still results in CHIRP auto-detecting the baud as 9600.
This is the APRS/TNC baud rate, not the one for the PC, AFAIK, so it's unrelated. Since the D72 uses a USB port for the PC connectivity, it's possible that it will just speak to us in whatever rate we try first, which might mean we're currently auto-detecting something slow. I'll try to get my hands on a D72 soon and see if I can poke around a bit.
The APRS/TNC speed is actually option 311, Int TNC->Data Speed, which is 1200 or 9600 only. AFAIK, option 331 is used for peripheral devices plugged into the USB port such as weather stations or GPS loggers. I only tried it here because it was only radio setting I could find that remotely pertains to the PC serial baud rate.
FWIW, the baud detection in kenwood_live.py:get_id() indeed only tries the baud rate there in ascending order and stops at the first successful one, but even when I manually invert the list, 9600 is the only one detected:
[2019-12-09 15:14:10,563] chirp.ui.mainapp - DEBUG: User selected Kenwood TH-D72 (live mode) on port /dev/cu.SLAB_USBtoUART [2019-12-09 15:14:10,572] chirp.drivers.kenwood_live - INFO: Trying ID at baud 115200 with delimiter "('\r', ' ')" [2019-12-09 15:14:10,675] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: ID [2019-12-09 15:14:11,181] chirp.drivers.kenwood_live - ERROR: Timeout waiting for data [2019-12-09 15:14:11,181] chirp.drivers.kenwood_live - ERROR: Giving up [2019-12-09 15:14:11,182] chirp.drivers.kenwood_live - INFO: Trying ID at baud 115200 with delimiter "(';', '')" [2019-12-09 15:14:11,286] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: ID; [2019-12-09 15:14:11,792] chirp.drivers.kenwood_live - ERROR: Timeout waiting for data [2019-12-09 15:14:11,792] chirp.drivers.kenwood_live - ERROR: Giving up [2019-12-09 15:14:11,792] chirp.drivers.kenwood_live - INFO: Trying ID at baud 57600 with delimiter "('\r', ' ')" [2019-12-09 15:14:11,896] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: ID [2019-12-09 15:14:12,402] chirp.drivers.kenwood_live - ERROR: Timeout waiting for data [2019-12-09 15:14:12,402] chirp.drivers.kenwood_live - ERROR: Giving up [2019-12-09 15:14:12,402] chirp.drivers.kenwood_live - INFO: Trying ID at baud 57600 with delimiter "(';', '')" [2019-12-09 15:14:12,506] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: ID; [2019-12-09 15:14:13,011] chirp.drivers.kenwood_live - ERROR: Timeout waiting for data [2019-12-09 15:14:13,011] chirp.drivers.kenwood_live - ERROR: Giving up [2019-12-09 15:14:13,011] chirp.drivers.kenwood_live - INFO: Trying ID at baud 38400 with delimiter "('\r', ' ')" [2019-12-09 15:14:13,115] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: ID [2019-12-09 15:14:13,620] chirp.drivers.kenwood_live - ERROR: Timeout waiting for data [2019-12-09 15:14:13,620] chirp.drivers.kenwood_live - ERROR: Giving up [2019-12-09 15:14:13,620] chirp.drivers.kenwood_live - INFO: Trying ID at baud 38400 with delimiter "(';', '')" [2019-12-09 15:14:13,724] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: ID; [2019-12-09 15:14:14,228] chirp.drivers.kenwood_live - ERROR: Timeout waiting for data [2019-12-09 15:14:14,229] chirp.drivers.kenwood_live - ERROR: Giving up [2019-12-09 15:14:14,229] chirp.drivers.kenwood_live - INFO: Trying ID at baud 19200 with delimiter "('\r', ' ')" [2019-12-09 15:14:14,333] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: ID [2019-12-09 15:14:14,839] chirp.drivers.kenwood_live - ERROR: Timeout waiting for data [2019-12-09 15:14:14,839] chirp.drivers.kenwood_live - ERROR: Giving up [2019-12-09 15:14:14,839] chirp.drivers.kenwood_live - INFO: Trying ID at baud 19200 with delimiter "(';', '')" [2019-12-09 15:14:14,943] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: ID; [2019-12-09 15:14:15,449] chirp.drivers.kenwood_live - ERROR: Timeout waiting for data [2019-12-09 15:14:15,449] chirp.drivers.kenwood_live - ERROR: Giving up [2019-12-09 15:14:15,449] chirp.drivers.kenwood_live - INFO: Trying ID at baud 9600 with delimiter "('\r', ' ')" [2019-12-09 15:14:15,559] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: ID [2019-12-09 15:14:15,678] chirp.drivers.kenwood_live - DEBUG: RADIO->PC: ID TH-D72 [2019-12-09 15:14:15,678] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: AI 0 [2019-12-09 15:14:15,788] chirp.drivers.kenwood_live - DEBUG: RADIO->PC: ?
I can't imagine that the D700 from yesteryear can do 57600 and a modern HT like the D72 is limited to 1980s baud rates :)
That would've been my thought as well :) I'd be happy to try out any other tests you can think of.
James VE7JWK
The APRS/TNC speed is actually option 311, Int TNC->Data Speed, which is 1200 or 9600 only. AFAIK, option 331 is used for peripheral devices plugged into the USB port such as weather stations or GPS loggers.
Yeah, I meant the serial-side not radio-side TNC baud rate. I'm not sure how those physically interface with the radio (is the usb port repurposed?) but I expect(ed) that it didn't affect the actual using-USB-as-USB rate, which I think you've confirmed.
FWIW, the baud detection in kenwood_live.py:get_id() indeed only tries the baud rate there in ascending order and stops at the first successful one, but even when I manually invert the list, 9600 is the only one detected:
Wow.
That would've been my thought as well :) I'd be happy to try out any other tests you can think of.
Hrm, well, I don't have one here to poke at, but it sounds like you probably did what I would have. Have you tried the MCP program to see if it appears to only operate at 9600?
I guess the next question then is: why did you like the live mode when it's so slow? Is there something bad about the clone mode support? I like live mode for the radios that support it because you get instant feedback about memories being good, but the async nature of that indication has always been pretty janky. That, and my kenwoods all just do command mode (driver-wise at least).
--Dan
On 10/12/19 3:19 pm, Dan Smith via chirp_devel wrote:
FWIW, the baud detection in kenwood_live.py:get_id() indeed only tries the baud rate there in ascending order and stops at the first successful one, but even when I manually invert the list, 9600 is the only one detected:
Wow.
I took a look at this a while ago. From memory, even though it appears t loop through a list (in the wrong order) there's actually a hard coded value in there somewhere. That bit of code needs a re-write.
I got my th-d74 operating at much faster speeds after sorting that out. I will dig out the code if you want it.
Hrm, well, I don't have one here to poke at, but it sounds like you probably did what I would have. Have you tried the MCP program to see if it appears to only operate at 9600?
I just tried MCP-4A on my Window laptop, there's no options in it to set the baud or see what it's using. Also, while the CP210x virtual comport driver properties allow you to change the port's baud from 9600 to, say 57600, there didn't seem to be any change in cloning speed by doing so, nor could I see anything relevant in the USBPcap traces I took during a couple of tests.
I guess the next question then is: why did you like the live mode when it's
so slow? Is there something bad about the clone mode support? I like live mode for the radios that support it because you get instant feedback about memories being good, but the async nature of that indication has always been pretty janky. That, and my kenwoods all just do command mode (driver-wise at least).
Honestly, I prefer the D72's clone driver, as a full read or write operation takes <20 seconds total with it. That said, the driver was broken for several years due to a bug relating to VFO filtering (eventually fixed in #1611). While it works great now, anyone who tried to use it during the time it was busted are likely still using the live version, whether out of lack of trust or sheer habit.
The live version under the existing UI is ok too. It takes a few minutes to do the initial read, but then each edit gets instantly applied/rejected. My concern was mainly that the new UI greatly increases the amount of time to sync the changes back for the live driver, which some people might not be happy about :) However, if you can add the ability to just sync the dirty memories edited during the same session the radio was read during, that'd probably make it a non-issue.
That said, regardless of the impact to this specific radio/driver, the new UI still seems like a positive thing overall.
Cheers, James VE7JWK
I just tried MCP-4A on my Window laptop, there's no options in it to set the baud or see what it's using. Also, while the CP210x virtual comport driver properties allow you to change the port's baud from 9600 to, say 57600, there didn't seem to be any change in cloning speed by doing so, nor could I see anything relevant in the USBPcap traces I took during a couple of tests.
Yeah, changing that default won't do anything for any non-DOS app from this century. In order to see what rate MCP is using requires something like portmon.
Honestly, I prefer the D72's clone driver, as a full read or write operation takes <20 seconds total with it. That said, the driver was broken for several years due to a bug relating to VFO filtering (eventually fixed in #1611). While it works great now, anyone who tried to use it during the time it was busted are likely still using the live version, whether out of lack of trust or sheer habit.
Okay, well, it sounds like maybe the best thing to do would be to just not expose the live driver for that radio in the UI. It might be useful for someone using chirp as a library to control the radio, but it sounds like general purpose usage makes it pretty pointless. When you were using the old UI, did you know you could hit Esc to stop it loading the whole thing and then refresh certain regions to avoid it doing all the stuff in the background? Moot for the new interface though, of course ... :)
The live version under the existing UI is ok too. It takes a few minutes to do the initial read, but then each edit gets instantly applied/rejected. My concern was mainly that the new UI greatly increases the amount of time to sync the changes back for the live driver, which some people might not be happy about :) However, if you can add the ability to just sync the dirty memories edited during the same session the radio was read during, that'd probably make it a non-issue.
Certainly for the live-only radios, although on my D700 the "upload" is pretty quick. My D710 will do 115200 but I haven't lugged a laptop out to the Jeep to try it on the new interface yet.
That said, regardless of the impact to this specific radio/driver, the new UI still seems like a positive thing overall.
Yep. I spent some time trying to make the new "treat it like a clone radio" interface even more seamless with the ability to save an "image" and such, but I think it's going to take a more substantial refactor to make that happen properly.
Anyway, thanks for the feedback on the D72 issue and its relation to this effort.
--Dan
participants (7)
-
Aaron Pelly -
af5mi＠yahoo.com -
Dan Smith -
Derek Chauran -
James King -
Jim Unroe -
Tony Fuller