[Hamlib-developer] API outstanding issues

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

Hi all!

Frank, I know you're moving, that's why I tried to not
bother you too much. Let me know when you will have a rest,
so we can eventually release a 1.1.0 hamlib version, and
advertise for it (as an alpha version, of course).
Anyway, hope everything's going well with your installation
in your new house, that must be a lot of work!

Lately, I've been playing with various bits of hamlib.
I tend to substitute the CVS reports to any more human readable ones,
sorry about my lazyness :)
* Well, after some tweakings, "make distcheck" works, so does "make dist".
It is very handy to create a clean release, with all the tagged files
to be distributed in the tar ball, in the right directory and 
correctly named. Check out the Makefile.am files if your favorite file
is missing from the dist.

* Besides misc updates, the API changed significantly on the way
radio levels are set and retrieved. See rig_set_level and rig_get_level
for more information. In a nutshell, a bunch of get/set distinct
functions have been multiplexed in one set_level/get_level pair.
Hope that won't complicate too much the backend implementation.


* As you may noticed, rig_set_tone functions are gone.
They have been replaced by the following functions:

	rig_set_ctcss
	rig_set_dcs

However, Hamlib is still lacking their squelched counterpart.
What do you think of creating these?

extern int rig_set_ctcss_sql(RIG *rig, unsigned int tone);
extern int rig_get_ctcss_sql(RIG *rig, unsigned int *tone);
extern int rig_set_dcs_sql(RIG *rig, unsigned int code);
extern int rig_get_dcs_sql(RIG *rig, unsigned int *code);

A tone/code of 0 would turn off the CTCSS/DCS squelch,
any other value would turn it on.

* I'm still not happy with the rig_set_mode/rig_get_mode.
  Frank, what do you think of getting rid of set_passband/get_passband
  in favor of the following?

 int rig_set_mode(RIG *rig, rmode_t mode, pbwidth_t width);
 int rig_get_mode(RIG *rig, rmode_t *mode, pbwidth_t *width);

* Testing the rig_set_mem and rig_get_freq, I realized that rig_get_freq
  would not handle the case where the freq was undefined (ie. blank channel).
  How can we solve this problem? so far, I can see two solutions.
  The first one consists in assigning a negative value in the freq variable
  in order to tell it is undefined. The second solution I would rather prefer,
  relies on the RIG_Error code returned by the function.
  What do you think?  Do you see another solution?

* News:
	- new AOR backend for the AR8200 scanner, far from complete.
	Written from specs, untested since I don't own such a toy. 
	- rigctl, a new test program, to test any Hamlib function.
	It runs interactively now, but will work from command line soon!
	- rigmatrix, a new combined list/dump program, that creates
	a table of supported radios in HTML format, with png pics
	for the rx/tx ranges (thanks to GD lib).
	The HTML output is rather ugly, but at least you got the
	information :) Any improvement is welcome! You can check
	it out at the following URL:
		http://f4cfe.free.fr/ham/hamlib/rigmatrix.html


Cheers,

-- 
Stephane