Re: [Hamlib-developer] what's up?

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

On Thu, Oct 11, 2001, Robert Steinhäußer wrote:
> > > Sorry, but I still haven't tested our IC275 and 475 at home. Have to find
> > > the old self-built interface first and then visit mom (DK3XJ) :)
> > >
> >   Great! She will be happy to see you, but first wait IC275 and 475
> >   are added..
> 
> Oops... isn't it a C-IV device as well? I really have to get that stuff
> out of the box on the shelf :-)
 
Yes it is. CI-V id $10 and $14. However, I still have to find the specs,
brochures, whatever, to fill in the caps..

> > 	Let me know if some functions are missing in Hamlib, or if you
> >   think the design is not appropriate. Accessing the caps/state directly is
> >   recommanded, instead set_conf/get_conf should be used, provided more
> >   parameters are declared (yet to be done). Maybe there should be some
> >   config data file support in Hamlib, regardless the application.
> >   What do you think?
> 
> I am trying to figure out why kdevelop wants to have -fno-exceptions in
> the CXXFLAGS. Any ideas? I removed it manually from configure, so now I
> can at least compile with <hamlib/rigclass.h> included.

no clue. I'm not an expert in C++. Anyone?

> Kontakt has an own static class RigCaps with member functions that do a
> get_rig_caps(rig_model_t) and return one specific value: A few
> things I need to show the user before selecting a device: mfg_name,
> model_name, rig_type, and a QString containing a textual representation of
> the status (alpha, ...). Or does hamlib(++) already supply this and I
> missed it?

I don't think so. But it would sure make others happy if such facilities
were present in hamlib(++). IMO, the textual representation
of status/mode/etc. should be in hamlib, no doubt. For the other functions,
let me have a look at your class RigCaps, and I'll see where it belongs.
Anyone is free to patch too.

> Config file in hamlib: I think the user would get too much "involved" with
> the lib, which should only be a background thing for the "real app". The
> user should be able to install a new rpm at any time without having to
> look for some config file somewhere. And, he has to do some settings in
> the application anyway, so put it all in there, even though he will have
> to enter the same data once(!) in each app.

Or at least, Hamlib should offer all the primitives to manage configuration
file?

> How do I find out which device need which specific settings? Like
> baudrate, target IP address, etc. What is the struct confparams in rig.h?
> I am focussing completely on the <hamlib/*.h> includes and not really
> reading the hamlib source much (stupid app writers shouldn't have to
> anyway :))

I agree with you, and that's the point of having documentation. 
On this regard, the in-source documenting should be more verbose
in the set_conf/get_conf section. In the meantime, have a look
at src/conf.c. Right now, only "rig_pathname", "write_delay" and alike
are available. Baud rate and such should be added in there...
 
> >   Yep, as soon as I have downloaded the 8MB+ for the qt upgrade...
> 
> Which upgrade? This is Qt2-stuff, I'm not using Qt3 here.

The libqt-dev package depends on a newer libqt2, and a zillon of other
libraries. This will be done this week-end.

BTW, I'm going right now /P out-door (friday off, thanks to french "35 hours").
From time to time, I'll be calling CQ Hamlib on 21.250MHz..

73, Stephane - F8CFE