Re: [Hamlib-developer] Proposal

[Luc L. <lx...@qs...>]

Hi Folks,

On Mon, 09 Oct 2000, Stephane Fillod wrote:
>   Well, I've already asked myself if glib would be of any
>   help for Hamlib. In some cases yes, in other cases not.
>   If you ask me for a answer right now, I would say
>   no to glib. I know it would make things easier for us,
>   but do we need all these gizmos to have a real lib?
>   I mean It's so good to have something selfcontained,
>   that does not require you to install xx .DLL^H^H^H^H
>   shared libraries to run.

I fully agree with you, Stephane

>   REM: I do recognize glib has plenty of cool stuff, and is very
> 	portable.
>
>   Ok, that's my answer today. It could change, especially if
>   we need more and more of this kind of reusable code.
>   Actually, this is a point where I'd love to see other
>   developpers (other than you and me) debate upon...
>
>
> Fresh news:
> ----------
> * added dynamic backend loading (still need the LD_LIBRARY_PATH though)
> * a new listcaps to list all known caps
> * include/rig.h moved to include/hamlib/rig.h
> * file buffered access, this works in parallel with unbuffered.
> 	It lets you do read 1 byte at a time, at no IO penalty.
> * added transceive mode, ie. asynchronous rig notificication handling
> 	It works quite nice with SIGIO and sigaction. see testtrn
> * More icom stuff
>
> For details, please see cvs-digest
>
> So what do you think of what we got? Can we make a hamlib-1.1.0
> release and call for help? We DO need help to finalize the API,
> choose the function names and semantics, etc.
> Potential Hamlib users are already knocking at the door!
>
> Cheers,

I just took a look at the rig.h file, and was a bit suprised to read how you 
use the mode. Is it not easier use an rig_mode_t and an rig_bandwidth_t? At 
least for the USB/LSB modes? I also thing that RTTY is not really clear 
enough... Some rigs make afsk, others afsk or fsk... Ans how to know if they 
do the acually USB or LSB? (Especially if I think on my psk31 project thats 
important to know)


-- 
Greetings, Luc