[Hamlib-developer] target VFO [was Re: Hamlib-cvs-digest digest, Vol 1 #29 - 1 msg]

[Stephane F. <f4...@fr...>]

On Thu, Dec 07, 2000, on hamlib-cvs-digest, Frank Singleton patched:
> Index: ft747.c
> ===================================================================
> RCS file: /cvsroot/hamlib/hamlib/ft747/ft747.c,v
> retrieving revision 1.21
> retrieving revision 1.22
> diff -C2 -r1.21 -r1.22
> ***************
> *** 278,281 ****
> --- 278,283 ----
>     rig_debug(RIG_DEBUG_VERBOSE,"ft747: requested freq = %Li Hz \n", freq);
>   
> +   ft747_set_vfo(rig, vfo);	/* select VFO first , new API */
> + 
>     to_bcd(bcd,freq,8);
>   
[...]
> ***************
> *** 504,507 ****
> --- 554,559 ----
>     rig_s = &rig->state;
>   
> +   ft747_set_vfo(rig,vfo);	/* select VFO first */
> + 
>     switch(ptt) {
>     case RIG_PTT_OFF:


  Actually, the <backend>_set_vfo() could be done in a generic way
  at the frontend level in rig.c, provided Hamlib knows through
  capabilities the rig can't address directly the different VFOs.
  The behaviour of Hamlib we still have to agree upon should assume
  IMO that whichever API function is called, the VFO selected by
  the previous rig_set_vfo must stay still. Here is an illustration:

	rig_set_vfo(VFO_A)
	...
	rig_set_freq(VFO_B,GHz(10.450))	/* geez, air-plane scatter! */
	...
	rig_get_vfo() -> VFO_A

  This means that for rigs that cannot address VFOs directly, the frontend
  (not the user application) should translate the previous sequence
  to this:

	rig_set_vfo(VFO_A)
	...
	if (!has_targetable_vfo) {
	  <backend>_set_vfo(VFO_B)
	  <backend>_set_freq(VFO_B,GHz(10.450))	/* VFO target useless here */
	  <backend>_set_vfo(VFO_A)
	}
	...
	rig_get_vfo() -> VFO_A

  Eventually, the frontend can "cache" which VFO is currently active,
  saving for some needless _set_vfo, but we have to take extra care that
  someone hasn't changed the VFO *manually* on the rig panel (however,
  having to do _get_vfo repeatedly would be a real pain).
  
  Anyway, I know you already have had this idea previously. The purpose of
  this mail is just to stress the "sharability" of such a piece of code
  (good feature to add for hamlib-1.1.1), and also to urge you 
  to release hamlib-1.1.0 now ;-)
  (remember "the release early, release often" rule of Linux)
  After all, hamlib-1.1.0 IS alpha quality, there's no shame about it,
  just lust for contributors.


  Cheers,

-- 
Stéphane