<div dir="ltr">OK cool. In that case, I'll leave the bug fix as is and make that the first patch. The goal<div>of the first patch is simply to ensure that if you download from a VX-8R, you don't </div><div>generate trace back errors and you don't get a Settings menu at all. In other words,</div><div>ensure that the correct code gets called for a given variant. </div><div><br></div><div>On an administrative note, should we just reject Issue 4881 and have me create a new</div><div>issue with the scope of work limited to the bug fix?</div><div><br></div><div>-Keith</div><div>KF7DRV</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 5, 2017 at 1:29 PM, Dan Smith via chirp_devel <span dir="ltr"><<a href="mailto:chirp_devel@intrepid.danplanet.com" target="_blank">chirp_devel@intrepid.danplanet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Perhaps instead of leading with the refactor of the VX8DRadio class<br>
> functions up to the VX8Radio class, I should first fix the obvious<br>
> bug of the VXDRadio functions getting called for a VX-8R. Next, I<br>
> would propose doing a patch that accommodates the memory layout<br>
> differences between the VX-8R and VX-8DR/VX-8GE. Then I would do a<br>
> patch that moves the common functions up to the base class (but<br>
> don't yet get called for the VX-8R). The last patch would be to<br>
> enable settings for the VX-8R by setting "has_settings" to True in<br>
> the get_features function and adding the special version of the<br>
> get_aprs_tx setting function in the base class (which would be<br>
> overloaded by the get_aprs_tx function in the VX8DRadio class).<br>
><br>
> Would this work OK for you?<br>
<br>
</span>Sounds awesome. I like awesome.<br>
<span class=""><br>
> Assuming I would start by fixing the issue of the bug where the<br>
> VX8DRadio functions are getting called when you download from a<br>
> VX-8R, I am not really happy with my current "fix" anyway. I ended<br>
> up adding separate models (VX-8R, VX-8DR, and VX-8GE) to the Yaesu<br>
> pull-down menu. This works fine but long-time VX-8* users of Chirp<br>
> would potentially not notice this change and select VX-8R when they<br>
> have a VX-8DR. Additionally, the pull down menu is busier since it's<br>
> now contaminated with variants.<br>
<br>
</span>I don't really think that's necessarily a bad thing. It's nice to be<br>
able to do everything automatically all the time, but Yaesus aren't very<br>
auto-detect-friendly. I don't really think it's a problem to make people<br>
choose the specific model, nor do I really think we'll see flak from<br>
users about it. Especially if we can point to "things work that didn't<br>
work before" type issues.<br>
<span class=""><br>
> This problem doesn't occur when opening any of the VX-8R, VX-8DR, or<br>
> VX-8GE image files. The specific model is apparently correctly<br>
> determined by the ident string at the beginning of the image file.<br>
> However, it definitely occurs when you download from the radio. I<br>
> haven't yet ferreted out the difference between model detection via<br>
> an image file open and model detection in the context of download<br>
> from a radio. I've noticed that in other drivers there are explicit<br>
> functions for identifying the radio. Is this some missing but<br>
> required functionality not in the current VX8 driver?<br>
<br>
</span>Well, those detection routines are to probe for sub-models to do<br>
different things during clone. I'm not sure that's really necessary<br>
here, unless you want to unify all of the variants into a single class,<br>
and just check properties of the image every time you want to do<br>
something that differs between them. That would be okay if you think<br>
it's worth it.<br>
<br>
I assume that this is doable at all with Yaesus because they barf their<br>
model number as the first thing when you hit clone on the radio right?<br>
They're not (AFAIK) interrogate-able for model info like every other<br>
radio on the planet.<br>
<span class=""><br>
> It also seems that Chirp has an Alias construct that seems to have<br>
> replaced the Variant construct. I'm clearly very confused around this<br>
> topic and a few pointers/suggestions would be most helpful!<br>
<br>
</span>Well, the reason we added that is because of all the models coming out<br>
of China that are just re-badged with no other apparent differences.<br>
Variant was added so you could have slight differences between the<br>
European and North American model of a radio. However, if the same radio<br>
is called "Foobar 9000" and "Whizbang 84" the variant isn't enough to<br>
distinguish them (that, and you don't actually need a different subclass<br>
for differences since there are none).<br>
<div class="HOEnZb"><div class="h5"><br>
--Dan<br>
______________________________<wbr>_________________<br>
chirp_devel mailing list<br>
<a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.<wbr>danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" rel="noreferrer" target="_blank">http://intrepid.danplanet.com/<wbr>mailman/listinfo/chirp_devel</a><br>
Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" rel="noreferrer" target="_blank">http://chirp.danplanet.com/<wbr>projects/chirp/wiki/Developers</a><br>
</div></div></blockquote></div><br></div>