Re: [Tlf-devel] TLF Improvement Suggestions

[Ed]

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


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.
>
>
> Thanks,
> Chris Maness KQ6UP


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


Ed W3NR