[Hamlib-developer] Re: vfo_t merging into trunk.

[Dale E. E. <de...@w-...>]

Stephane,

Yes, I'm *very* aware of your most discriptive dislike of parts of the
vfo_t I've described.

My current focus is not so much convincing you as proving the concept
with working code.  I'm getting real close to what I consider a fully
functional version.  Discussions can be pointless if the proposal is
easily
shown to be flawed.  Also, a working model will support my argument
if the current Hamlib can be demonstrated to be flawed or inadequate.
Either way, a working accessible model is a must.

I was happy to hear you like at least the CALL.  It very much made
sense to me.

The individual bits of my proposed vfo_t are of *much* less concern
to me than the way the API constructs it.  The current scheme is not
extensible.  Even if *none* of my bitmasks are added, the vfo_t should
be changed.  This bears repeating.  The additional masks are not as
important to me as how the vfo_t is handled.  Of this, the RIG_SET_VFO
is all important.  If you find something better that is likewise as easy

to understand, modify, and eliminates or reduces ambiguity, I'll be
quite happy (though maybe not entirely).

Thanks again for the feedback.

73's

Dale
KD7ENI