hamlib-developer

[Hamlib-developer] what's up?

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

Hi fellows,

I haven't heard about you since the release of hamlib-1.1.2. I hope
everything's fine on your side. I hardly believe 1.1.2 is so stable
that you haven't had to report bugs :)
Also, I'd love to hear from people succeeding in (or not) to run Hamlib
with any rig except the IC706 and FT847 (the only truly tested),
like the Kenwoods, the various receives, etc.

New stuff's coming out. Actualy I've commited a first version of
the RPC backend, which is nothing else that what anyone would expect
to have running on a desktop to share a rig among applications.
Well, right now, only set_freq and get_freq work, but it's a start.
This was just a proof of concept, and it works!
Just run "rpc.rigd" with appropriate args (similar to rigctl, -vvvv helps) 
and use the model 1901 on the client side, regardless how many 
they could be, and you're in business!
Any wishes? Comments? Feedback welcome!

Cheers,
Stephane / F8CFE

PS: fine work Terry on the Debian packages! Do you want to commit the
    scripts in the debian/ subdirectory?

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

[<rs...@su...>]

Hello out there,

On Mon, 8 Oct 2001, Stephane Fillod wrote:

> I haven't heard about you since the release of hamlib-1.1.2. I hope
> everything's fine on your side. I hardly believe 1.1.2 is so stable
> that you haven't had to report bugs :)

Well, it compiles without problems :-)

My today's copy from the CVS doesn't, though. After some disk scratching,
it says:

Making all in lib
make[1]: Entering directory `/usr/src/hamlib/lib'
Makefile:166: *** missing separator.  Stop.
make[1]: Leaving directory `/usr/src/hamlib/lib'
make: *** [all-recursive] Error 1

I'm using autoconf 2.52, automake 1.4-p5 and libtool 1.4.1.

> Also, I'd love to hear from people succeeding in (or not) to run Hamlib
> with any rig except the IC706 and FT847 (the only truly tested),
> like the Kenwoods, the various receives, etc.

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) :)

> Any wishes? Comments? Feedback welcome!

I'm working on my 'Kontakt' project (a GUI frontend for hamlib). Well, now
I know a lot more about C++ (and differences to C, like using member
functions for callback purposes... brrr!) and can actually give you a tree
view of all devices supported by hamlib. A rig can be selected in the list
(a subclass of QListViewItem now stores the rig_model_t entry), but that's
about it right now. No actual controls yet, first I want to have the
config data saved to/retrieved from the config file (hopefully this week).

If you *really* want to try it: http://sf.net/projects/kontakt -> cvs
instructions. But please give me some feedback.

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...

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

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

On Wed, Oct 10, 2001, Robert Steinhäußer wrote:
> My today's copy from the CVS doesn't, though. After some disk scratching,
> it says:
> 
> Making all in lib
> make[1]: Entering directory `/usr/src/hamlib/lib'
> Makefile:166: *** missing separator.  Stop.
> make[1]: Leaving directory `/usr/src/hamlib/lib'
> make: *** [all-recursive] Error 1
> 
> I'm using autoconf 2.52, automake 1.4-p5 and libtool 1.4.1.
> 
	You'll need automake 1.5. Otherwise, you may have a chance
 in regenerating all the .in files.

> 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..

> I'm working on my 'Kontakt' project (a GUI frontend for hamlib). Well, now
> I know a lot more about C++ (and differences to C, like using member
> functions for callback purposes... brrr!) and can actually give you a tree
> view of all devices supported by hamlib. A rig can be selected in the list
> (a subclass of QListViewItem now stores the rig_model_t entry), but that's
> about it right now. No actual controls yet, first I want to have the
> config data saved to/retrieved from the config file (hopefully this week).
 
	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?

> If you *really* want to try it: http://sf.net/projects/kontakt -> cvs
> instructions. But please give me some feedback.

  Yep, as soon as I have downloaded the 8MB+ for the qt upgrade...

Cheers,
Stephane - F8CFE

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

[<rs...@su...>]

On Thu, 11 Oct 2001, Stephane Fillod wrote:

> 	You'll need automake 1.5. Otherwise, you may have a chance
>  in regenerating all the .in files.

automake && ./configure && make install
works. Strange.

> > 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 :-)

> 	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.

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?

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.

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 :))

>   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.

Enough for today, more tmrw.

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...

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

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

[<rs...@su...>]

On Fri, 12 Oct 2001, Stephane Fillod wrote:

> 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) :)
>
> Yes it is. CI-V id $10 and $14. However, I still have to find the specs,
> brochures, whatever, to fill in the caps..

Oh, ok, so I'll search for the manual first.

> > 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?

Not a C++ problem. It seems like KDevelop sets this when compiling with
debug symbols. Don't know why. Adding "-fexceptions" to "own options"
doesn't help, as they are put on the command line before KDevleop's flags.
But without debug symbols it works.

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

Now if i exactly knew what a primitive is...

KDE has an own class KConfig, just do a config->SetGroup("xy"); and a
config->WriteEntry("name", value); and you get a
~/.kde2/share/config/prognamerc with:

  [xy]
  name=value

in it. I just have to know what to put there besides the rig numerical (as
below).

> > 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...

I have some time to read it at my grandparents' on Saturday. The regional
ham club meeting (Distriktsversammlung) is on Sunday, so the weekend is
already filled up

> 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..

OK, I have to leave now and catch my train home. We have our monthly local
ham meeting at 20:00.

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                         rs...@su...
http://1409.org                                   ro...@st...