Re: [Tlf-devel] TLF Improvement Suggestions

[w9ya]

Hey Chris, and the gang;

For what it is worth, I *totally* agree with the suggestion of emulating
the WR9R logger for ARRL FD. This would be a VERY big step-up for TLF
(imho). More especially if such an emulation also had the single screen
fly-up help AND the single screen fly up section sheet usefulness and
dummy proof workability of WR9R. <- Heck, just emulate WR9R's goodness and
simplicity verbatim and you got a WINNER.

"Just how popular is WR9R ?" -> Well, I know of MANY FD groups that keep
older 486 laptops around just to have the ability to boot into WR9R,
including my group. In our case we substituted solid state drives for the
floppy.


The other thing I would speak to is to suggest using "nano" as an editor
option. It seems to be very simple-minded as well. ALTHOUGH by emulating
WR9R's qso edit, a separate editor would be needed for in-use editing.


(Finally, I was able to get WR9R to work under linux many years ago with
keying. However in more recent testing I was NOT able to get the keying to
work here, for reasons that *may be* unrelated to WR9R. Both dosbox and
dosemu ran WR9R. (Dosbox just ran it without any user config twiddling,
including speaker audio be re-routed to alsa/oss.))

Vy 73;

Bob
w9ya


> 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.
>
> 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).
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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).
>
> 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
> (909) 223-9179