[chirp_devel] Adding Settings support to the VX8-R

[Keith Williamson]

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 at 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 at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20170605/8a679911/attachment-0001.html