[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tlf-devel] TLF Improvement Suggestions

From: Ed
Subject: Re: [Tlf-devel] TLF Improvement Suggestions
Date: Sat, 05 Jul 2008 13:09:05 -0400
User-agent: Thunderbird (X11/20080505)

Chris Maness wrote:
1.  VHF/UHF bands.  Available contest bands should be defined in each
particular contest's "rule" file not by program itself.

2.  Separate fields specifically for populating the correct adif fields for
the contests in question.  For example:  when it is in FD mode, the exchange
2A WWA should not just go in the comment field.  2A needs to go in the CLASS
field and WWA needs to go into ARRL_SEC field.  This would probably require
3 seperate entry fields (CALL, CLASS, ARRL_SEC).  These fields should be
re-definable -- so they could be used for other contest and other adif
fields (ie grid square).  This fields should be defined in the "rules" file
for that contest.

Seeing there has been no active maintenance on TLF for a long time, it would require someone else to step in and work on TLF.

3.  Also, their is no such mode DIGI in the adif spec.  Q's that have DIGI
in the mode field, get kicked out when I try to import into trusted QSL.  I
have to change by hand in another program.  RTTY, PSK31 etc, are acceptable
modes for tqsl.  It would be nice to have more choices in digi modes (just
legit ones that won't get kicked out by other apps).

The Digi mode was originally included in TLF strictly for RTTY contests.

4.  Better color scheme that does not get washed out by sunlight on a
computer screen.  (black and primaries like red and green would work here).

If you are using either Gnome or KDE why not use the included terminal. I had setup TLF to run from the Gnome terminal. This would allow you access to the palette to change the colors to your liking. Also you could easily setup a desktop launcher. The Gnome terminal help file has all the information on how to do this.

5.  Setting the CQDelay variable in the main config file does not seem to do
anything to effect the CQ delay.  It has to be set each time the program is

You don't mention what distro you are using, but if it Debian based, take a look in /etc/defaults.

6.  For field day, I was running the program on an asus eee (a diskless
micro PC w/ Xandros Linux, station was on battery power), and the cw speed
was unstable.  It kind of had a mind of it's own.  I do not know if this is
a platform specific problem, but I will play with this more later to see if
it does this on the i386 platform.

Xandros supplied a hacked version of their distro for Asus, so anything could be astray on this.

7.  The edit mode drops users into vi or some other arcane editor (yes I
know, I love VI's arcaness too), and out older crew absolutely had no clue.
I was looking to add pico, but it looks like this program has been
obsoleted.  However, I think that pico would even be too much for these
guys.  Is there a editor that emulates the old DOS text editor.  We need
something completely bonehead here.

I would vote for Nano on this one, but Gedit also works.

8.  A more complete on-line help system.  I was unable to figure out how to
switch between S&P modes and CQ modes for the CW macros.

They are terribly outdated and I haven't used TLF in a long time and really don't recall the how-to for this.

Here are some features that would be nice someday, but are not as crucial:

9.  I see the program has a CT emulation mode.  It would be nice if it had a
WR9R mode for FD.  This would make it VERY dumb dumb proof.

Start hacking the code ......thats the best idea I have.

10.  A GUI mode -- It would be nice to be able to use it in console or GUI.
I really like N1MM.  Maybe this would be a model to construct it on.  Again,
there should be a dumb dumb mode for this too as some of our club members
even complain that N1MM is too complex (a windows app).

Runs fine in both the Gnome and KDE terminals.

This is a complete list that I have come up with after actually using it in
a real multi opp contest situation w/ real users.  Many of these things only
revealed themselves as issues in a real contest environment.  If any others
would like to add to this feel free.  I think these changes would make it an
AWESOME logging program.

Chris Maness KQ6UP

And unless your good with perl, Xtlf is about out of the question.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]