Re: [Hamlib-developer] Musings on backend behavior

[Nate B. <n0...@ne...>]

* Stephane Fillod <f8...@fr...> [2002 Dec 01 17:32 -0600]:
> Like what? Can you give some example?

I tried to document these things in doc/README.ft920

In particular, if an application wants to set the VFO-B frequency on the
FT-920.  Is the application expected to call rig_set_vfo first?  If this
is done on the '920 then the A and B VFOs will swap places on the
display of the radio and then if rig_set_freq is called with VFOB then
what actually happens is the frequency that was shown as VFO A (main
display) will be changed and the original VFO B frequency will be
unchanged.

On the other hand, the '920 backend supports the RIG_TARGETABLE_ALL (I 
can only make a guess as to the design intent of this constant so my use 
is based on my assumption) constant as the VFO B can be set without VFO
swapping.

It's difficult to describe the behavior in text.

> I'd love such documentation exists. Unfortunately, the only thing I can
> do, is to reply the best I could to question when they are asked.
> Writing specification, as valuable as it can be, is time consuming when
> done alone. Any volunteer?

I realize that!  I guess I could add things to rig.h and rig.c as I
learn them and you can correct my errors.

> Sure a written definition is much needed! 
> 
> So far, it has not been done because:
> - lack of time and lust
                     ^^^^  Hmmmm.....
> - developers tend to prefer to develop rather than write documentation,
>   especially when they do this as a hobby

Sure, I can tell you it's much more gratifying to write working code.

> - the design of the API is not complete yet. It has to cover all the rig
>   combinations over there. BTW I'm still not satisfied with the vfo_t.
>   It may look silly to document something that's going to change in
>   the near future, waste of energy.

Okay, I've thought of some additions to the VFO constants.  Perhaps
you'd like to get away from constants completely?  I've refrained from
tinkering with rig.h as I think that's above my domain.  :)

> So let's be pragmatic. Everyone is encouraged to submit comments on
> existing flaws,limitations,.., and how they see the API should be designed,
> point by point.

This is a good area of discussion for those using Hamlib in their
applications.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamomoto