Well, one of the joys of Linux is that if you don't like the way the precompiled program works you are free to get the source and compile
it yourself. Not being a Real Programmer I can't say how hard it is to convert a compile-time option into a run-time option.
For something like gMFSK-hkj, I would compile it locally and then use something like checkinstall to create the .deb package and install it. I found this helped to keep track of software where I wanted to tweak the configuration and still keep it in the package tree.
Kev - K4VD
... Hamlib is a very nice general purpose one size fits all interface library. I have nothing against or for it. I tried using it from with gmfsk with limited
Message 1 of 9
, Apr 11, 2006
Hamish Moffatt wrote:
On Tue, Apr 11, 2006 at 08:48:44AM -0400, w1hkj wrote:
Hamish Moffatt wrote:
BTW, for the purposes of distributions (like Debian), compile-time
options are no good...
I am open to suggestions to resolve that issue Hamish. Some of the
patches (the user interface for example) probably should just be made a
part of the application. Others, like the interface to the CAT programs
(ArgoV, DeltaII, Icom728 and Kachina) could be run-time switches.
Well in the case of the CAT-type changes, wouldn't it be proper for
those changes to go into hamlib rather than directly into gMFSK?
Hamlib is a very nice general purpose one size fits all interface
library. I have nothing against or for it. I tried using it from with
gmfsk with limited success (it doesn't support all of the i/o I
desire). It does not purport to be a rig interface program, just a rig
i/o program. The DeltaII, ArgoV, Icom728 and especially the Kachina
CAT programs are rig control programs. In fact the Kachina program is
the only Linux program for controlling the Kachina (which is a computer
interface only rig ... no front panel what-so-ever). Controlling the
Kachina using hamlib did not work very well. I tried it. So I elected
to use my own i/o code to the transceivers. But the mods to gmfsk do
not impact on the continued use of hamlib for those users with a
different transceiver or need. If I had been successful in using
hamlib for the CAT programs I still would have had to provide a means
of communications between the gmfsk program and the transceiver control
program. Only one program at a time should be attempting to send
commands to the transceiver. If you look at the TenTecCAT.c source
code you will see that gmfsk and the CAT programs communicate using
shared memory. Very fast, very efficient. The actual i/o to the
transceiver is done in the CAT programs, which by the way can also run
stand-a-lone without gmfsk.
Your message has been successfully submitted and would be delivered to recipients shortly.
Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer.
We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.