Re: [Hamlib-developer] CQ CQ hamlib-developers..

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:
> 
> Frank Singleton wrote:
> >
> > I hate excuses, but, I am in the middle of a humungous project at work,
> > for at least the next 2 months or so.
> >
>   we all know what it is.
> 
> > I have CORBA running out of my ears :O
> >
>   Hopefully you will tame the beast :)
> 
>   I envision distributed hamlib applications, interacting
>   through CORBA...
>   no, just kidding (would be cool though with Bonobo :-)


> 
> > Does my yaesu stuff still compile  ok ?

Actually, I ran it against my FT747 anf FT847 and it all looked
ok .


> >
> yep, every time I modify the front-end, I try to keep the CVS rep
> in a compilable state (this is all about total quality ethic, hi).
> Even if backends may not have implementation of the newest features, they
> still support the simple commands (set_freq, set_mode, etc.)
> 
> BTW, I have a batch of frontend updates I've proposed recently on the list.
> Do you think they're OK, and I can go ahead modifying backend ends
> accordingly and commiting in?
> A new version of Hamlib definitely needs to be released soon too!


Yes I agree. But I have an intersting idea .............


Here we are populating an ever growing rig_caps struct, with some
cababilities and function pointers to our API.

Why dont we modify this a little?

Create a list (enum?) of capabilities funtion codes,
and then when we populate our rigg_caps, it actually
consists of a list tuples, appropriately terminated.


The tuple is a function dode, and matching data (or fn pointer).

enum function_capability {
  FC_INIT,
  FC_CLEANUP,
  ..
  FC_RX_LIST,
   ..

  FC_TX_LIST,

  ..
 
   etc..

}


Then ...............

eg:

 Instead of 

<snip>

  ft747_init, 
  ft747_cleanup, 
  ft747_open,				/* port opened */
  ft747_close,				/* port closed */
  NULL,				/* probe not supported yet */

  ft747_set_freq,		/* set freq */
  ft747_get_freq,		/* get freq */
  ft747_set_mode,		/* set mode */
  ft747_get_mode,		/* get mode */
  ft747_set_vfo,		/* set vfo */
  ft747_get_vfo,		/* get vfo */
  ft747_set_ptt,		/* set ptt */
  ft747_get_ptt,		/* get ptt */

  NULL,				/* add later */
  NULL,				/* add later */




<snip>


we have


{ {FC_INIT, ft747_init}, 
  {FC_SET_PTT, ft747_get_ptt,},
  {FC_CLEANUP, ft747_cleanup,}

 .... etc

  {FC_RX_LIST, { { {1500000,1999900,FT747_OTHER_TX_MODES,5000,100000},
/* 100W class */ 
    {1500000,1999900,FT747_AM_TX_MODES,2000,25000},	/* 25W class */
    
    <snip>
    
    {24500000,24999900,FT747_OTHER_TX_MODES,5000,100000},
    {24500000,24999900,FT747_AM_TX_MODES,2000,25000},
    
    {28000000,29999900,FT747_OTHER_TX_MODES,5000,100000},
    {28000000,29999900,FT747_AM_TX_MODES,2000,25000},
    
    RIG_FRNG_END, }}

  }

  { FC_WHATEVER, .. }

   etc..

}


This  way, I dont go blind trying to fill the correct line in the
rig_caps struct
for a certain function pointer,or freq range list, and I dont care what
order they are listed.

This way, I dont have to jump over "NULL" entries etc..

Just some minor tweaks for the backends, and a little for the front
end. :)


Coments ??

Cheers / Frank..

> 
> Cheers,
> --
> Stephane
> 
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> http://lists.sourceforge.net/lists/listinfo/hamlib-developer

-- 
Cheers / Frank 

73's de vk3fcs & km5ws