ubuntu-hams team mailing list archive

[Nate Bargmann <n0nb@xxxxxxx>]

* On 2010 08 Jun 19:08 -0500, Paul Schulz wrote:
> Hi Nate and the group..
> 
> I also have an 'on-going' hacking project on a contest logger.
> - Based on 'xlog' (Ubuntu package)
> - My changes are in a git repository here:
>     http://git.mawsonlakes.org/cgi-bin/gitweb.cgi?p=paul/xlog
> - Written in c.

Hi Paul.

Sounds like you're having 'fun'.  ;-)

Personally, I'd hesitate to suggest C for this project.  The so-called
scripting languages offer too many useful features for this sort of
project not to take advantage of them.

The following is long as I'm explaining some things for those who may
not have operated in a contest or used a contest logger before.

> I attempting to convert the GUI GTK to libglade to make it more
> customisable at runtime, and suitable for other radio logging other
> than just contests... (eg nets, message passing) and I am treating it
> as a personal learning project.

Certainly nothing wrong with learning something on one's own time.  I
suspect many of us here are self-taught.  Regardless, your knowledge can
be quite helpful.

> There are some common things that would help both projects..
> 
> - standardised log format (eg. use SQLlite, or a tagged LDAP type format)

I've often wondered about what is "best".  IMO, data integrity is at the
top of the list.  Murphy loves hamshacks.  Murphy loves hamshacks during
a contest period even more!  So before any discussion of data formats
begins, data integrity comes first.

My experience is with K1EA's CT written for DOS in the '80s and
maintained up until a few years ago.  Back before laptops with charged
batteries and UPS units became common, we would use a desktop computer
running on generator power for ARRL Field Day and through all manner of
failures (thankfully no disk crashes) I've never seen more than the QSO
on screen before its entry be lost.  That is a track record I think is
crucial.  So assuring the data is written to the disk after each QSO is
a requirement, IMO.  As Linux caches disk writes, it may be over kill to
sync after each QSO entry.  This requires discussion.

> - well defined data entry 'flow'.

I presume you mean in the UI?  No matter the UI, I think it is important
that all logging operations be possible from the keyboard--no mouse
required--and if the app loses focus that it be able to make the last
active entry field active once focus is regained.

I always found CT easy to use and teach to others as its entry flows as
though one is typing a letter.  First the call is typed, then the
spacebar is pressed and the cursor jumps to the next entry field (for
example in CQWW it jumps to the Zone field) and the next until <Enter>
is pressed to log the contact.  The QSO is added to the screen in place
of the previous QSO and the log advances up by one line and the entry
fields are cleared for the next contact.  Time and band/freq are
recorded automatically.

In CT the <Space> acts as a "super tab" as I alluded to above in that it
may skip a field.  In contests where a "signal report" is required as part
of the exchange an actual report is rarely given, instead everyone just
sends 59/599 (depending on the mode) and leaves it at that.  So the
<Space> jumps around that field and instead takes the cursor to fields
where variable data is entered.  But what does the op do when another op
sends a "real" report?  He can ignore it(!) or use the <Tab> key to
reach all fields.  Left/right arrow keys, the <Backspace>, and
<Delete> keys behave in each field in the manner one would expect.

Editing a QSO is accomplished by using the <Up> arrow or <Pg-Up> key and
scrolling up to the QSO that needs changed.  The editing keys are the
same as in the QSO entry field and <Enter> commits the changes to the
log.  Then one simply scrolls down to get back to the entry field.

If one has enterted any amount of QSO data but the contact is not
completed, Alt-W or <F11> will "wipe" the QSO entry fields.  Other keys
are Alt-F1/F2 for Band Down/Up and Ctl-F1/F2 for Mode Down/Up.  Other
combinations of keys do things like send CW or voice keyer messages and
configure other aspects of information on the screen or configuration of
CT.

> - standard 'hot/shortcut keys'

Some will be problematic as the various desktop environments reserve
many for themselves.  As key combinations such as Ctl-F1/F2 change
workspaces, or Alt-F1/F2 perform other functions, it's not really
possible to expect them to be available to our program.  Fabian's
solution is to have the user type the band such as 20m or operating
frequency--14025--into the Call field and have YFKtest take the
appropriate action.  Mode could be done likewise with USB, LSB, CW,
DIGI, etc. being keywords that are parsed for when <Enter> is pressed.

A GUI will have other options such as toolbar buttons to change
band/mode, etc.  Even though those can be manipulated with the mouse, it
must always be possible to do those functions from the keyboard, IMO.

By now, I think it must be realized that key stroke for key stroke
implimentation of the CT UI cannot be accomplished so we do what we can
and find other ways.

> xlog currently uses a fixed testfile format. You can add fields, but
> removing fields will delete historical data.

I used Xlog for a time.  I was never a fan of the flat text file format
although its big advantage is simplicity and human readability.  This is
wide open for discussion.

> I was also blogging about my progress.. before that came to a grinding halt.
> http://mawsonlakesorg.blogspot.com/2010/03/part-3a-xlog-preparing-to-hack.html

Looks familiar.  :-)

A final thought.  While I've been hacking on a Curses based program, it
is necessarily limited although does not require a graphical desktop or
GUI toolkit dependencies to use.  I think this is a worthwhile area for
discussion as graphical features such as grayline display, QRA maps,
great circle maps, and the like may be desired features.  Curses is also
quirky and must be used with care as the display becomes more complex.

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://n0nb.us/index.html