Hi Dan,
Understand and I am willing.
Perhaps instead of leading with the refactor of the VX8DRadio class functions up to the VX8Radio class, I should first fix the obvious bug of the VXDRadio functions getting called for a VX-8R. Next, I would propose doing a patch that accommodates the memory layout differences between the VX-8R and VX-8DR/VX-8GE. Then I would do a patch that moves the common functions up to the base class (but don't yet get called for the VX-8R). The last patch would be to enable settings for the VX-8R by setting "has_settings" to True in the get_features function and adding the special version of the get_aprs_tx setting function in the base class (which would be overloaded by the get_aprs_tx function in the VX8DRadio class).
Would this work OK for you?
Assuming I would start by fixing the issue of the bug where the VX8DRadio functions are getting called when you download from a VX-8R, I am not really happy with my current "fix" anyway. I ended up adding separate models (VX-8R, VX-8DR, and VX-8GE) to the Yaesu pull-down menu. This works fine but long-time VX-8* users of Chirp would potentially not notice this change and select VX-8R when they have a VX-8DR. Additionally, the pull down menu is busier since it's now contaminated with variants. This problem doesn't occur when opening any of the VX-8R, VX-8DR, or VX-8GE image files. The specific model is apparently correctly determined by the ident string at the beginning of the image file. However, it definitely occurs when you download from the radio. I haven't yet ferreted out the difference between model detection via an image file open and model detection in the context of download from a radio. I've noticed that in other drivers there are explicit functions for identifying the radio. Is this some missing but required functionality not in the current VX8 driver? It also seems that Chirp has an Alias construct that seems to have replaced the Variant construct. I'm clearly very confused around this topic and a few pointers/suggestions would be most helpful!
Cheers,
Keith KF7DRV
On Mon, Jun 5, 2017 at 11:36 AM, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
The patch is somewhat lengthy due to the fact that I promoted most of the VX8DRadio class functions to the VX8Radio base class. This left the VX8DRadio class with just functions that were somewhat different for the VX-8DR and VX-8GE (e.g. _get_aprs_tx_settings) or unique to the VX-8DR and VX-8GE (e.g. _get_aprs_smartbeacon).
Hopefully, I haven't introduced any PEP-8 violations..PyCharm is pretty good at yelling at me about those. Please review and feel free to toss the whole thing if it's felt that I'm off base on this approach.
I'm okay with the refactor (in fact, I'm sure it's sorely needed), but do you think you could split this up into smaller pieces? Ideally, you'd lead with a refactor of things up into the base class, and then follow on with the "new" stuff in a separate patch. If we merge and release this, and then in six months someone reports a weird regression, it'll be hard to do anything other than revert this entire patch to see if it solves the problem.
I know it'll be some work, but... are you willing?
Thanks!
--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