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