[Xlog-discussion] A few xlog patches

[Werner Koch]

Hello!

Now that my transceiver sits close to my monitor I started to make real
use of xlog. It is a nice and small Unix program and should be
sufficient for me. However, there are a couple of peculiarities: For
example on Saturday I did some contest QSOs and got one dup response
("we already had a QSO"). The worked before windows showed that QSO but
I didn't realized that fast enough. So a better indication is needed to
make such things obvious. I did some patches:

1. Change the color of a new callsign when it has been worked.

The color is changed on an exact match. It would be better to also
indicate a fuzzy match here. The whole thing is pretty important to
quickly check whether a station has already been worked; for example
in a contest.

Using a fixed color is a bit crude but it is a first step for an
improved answer-back during data entry.

2. Just one button to set date and UTC to the current time.

It does not make sense to be able to set the current time but keep
the existing date. Better one button for this. Note that the date
can anyway be edited manually to any value.

3. Change the order of fields in the QSO frame

Except when typing in old log paper entries or similar, there is no
reason that the order must follow the order in the log windows.
From a usage point of view the new order seems to be better. For
example the band and mode is rarely changed and should thus not get
into the way when logging a new QSO. The call and the RSTs should
be the first and easiest to enter data. Actually the UTC should
even come after the call but I didn't do that because another patch
should fill in the UTC at save-time - this is a better for contests.

as well as a few supporting changes. My goal is to make xlog ready for
real contest use up to a level that it can compete with whatever the
other hams in my club are using on Windows. I also looked at fldigi,
which is a great set of tools, but given that I am more a C and Gtk+ guy
I decided to give xlog a try.

Given that I basically lost all my CVS knowledge, I took the Savannah
xlog2 repo and imported it into a new Git repository for my local work.
You can find it at

git://git.gnupg.org/people/wk/xlog.git

Now the question is whether you like my changes at all and, if so, how
shall I send you the patches?

I would also like to discuss possible new features here to see whether
my patches make sense for a wider community. The next feature I am
looking into is an automatic RST+nnn counter and faster and more safe
contest logging options.



Salam-Shalom,

Werner

[Andy Stewart]

Post by Werner Koch
Hello!

Hello Werner,

As the maintainer of the Xlog software, I'd like to thank you for your
enthusiasm and willingness to share your ideas and code with the community.

Post by Werner Koch
Now that my transceiver sits close to my monitor I started to make real
use of xlog. It is a nice and small Unix program and should be
sufficient for me. However, there are a couple of peculiarities: For
example on Saturday I did some contest QSOs and got one dup response
("we already had a QSO"). The worked before windows showed that QSO but
I didn't realized that fast enough. So a better indication is needed to
1. Change the color of a new callsign when it has been worked.
The color is changed on an exact match. It would be better to also
indicate a fuzzy match here. The whole thing is pretty important to
quickly check whether a station has already been worked; for example
in a contest.
Using a fixed color is a bit crude but it is a first step for an
improved answer-back during data entry.

The above seems like it would be a relatively simple, but useful addition.

Post by Werner Koch
2. Just one button to set date and UTC to the current time.
It does not make sense to be able to set the current time but keep
the existing date. Better one button for this. Note that the date
can anyway be edited manually to any value.

I'm curious...did you remove a button from the GUI? Do you have a
screenshot?

Post by Werner Koch
3. Change the order of fields in the QSO frame
Except when typing in old log paper entries or similar, there is no
reason that the order must follow the order in the log windows.
From a usage point of view the new order seems to be better. For
example the band and mode is rarely changed and should thus not get
into the way when logging a new QSO. The call and the RSTs should
be the first and easiest to enter data. Actually the UTC should
even come after the call but I didn't do that because another patch
should fill in the UTC at save-time - this is a better for contests.

I have a friend who has wished for a) a better/different order in the
New QSO frame, or b) the ability to add/delete those boxes at will, for
different contests, and c) the ability to enter a QSO *without* needing
the mouse. My friend's chief complaint is that tabbing over unused info
boxes is error prone and should be unnecessary. Toward that end, I'm
curious about your changes.

For example, in a 6m contest, the exchange might be callsign, signal
report, and grid locator, which is challenging to do with the current
software.

Post by Werner Koch
as well as a few supporting changes. My goal is to make xlog ready for
real contest use up to a level that it can compete with whatever the
other hams in my club are using on Windows. I also looked at fldigi,
which is a great set of tools, but given that I am more a C and Gtk+ guy
I decided to give xlog a try.
Given that I basically lost all my CVS knowledge, I took the Savannah
xlog2 repo and imported it into a new Git repository for my local work.
You can find it at
git://git.gnupg.org/people/wk/xlog.git
Now the question is whether you like my changes at all and, if so, how
shall I send you the patches?
I would also like to discuss possible new features here to see whether
my patches make sense for a wider community. The next feature I am
looking into is an automatic RST+nnn counter and faster and more safe
contest logging options.

I am interested in your ideas. I'd like to find a way to maintain a
balance between the casual users of Xlog and those who would like the
tool to be more user friendly for contest logging.

Thanks for sharing!

73,

Andy
Xlog Maintainer

[Werner Koch]

Hello Andy,

Post by Andy Stewart

Post by Werner Koch
1. Change the color of a new callsign when it has been worked.

The above seems like it would be a relatively simple, but useful addition.

I just fixed a little bug.

Post by Andy Stewart

Post by Werner Koch
2. Just one button to set date and UTC to the current time.
It does not make sense to be able to set the current time

I'm curious...did you remove a button from the GUI? Do you have a
screenshot?

Loading Image...

I removed the date button because the UTC button also fills in the
date. This also shows the reordered fields.

It might be better to have an in-entry button on the right side to fill
in the UTC and for contests it should be done anyway at save-time.

Post by Andy Stewart
I have a friend who has wished for a) a better/different order in the
New QSO frame, or b) the ability to add/delete those boxes at will,
for different contests, and c) the ability to enter a QSO *without*
needing the mouse. My friend's chief complaint is that tabbing over
unused info boxes is error prone and should be unnecessary. Toward
that end, I'm curious about your changes.

That is also my idea. I am thinking about a configurable order of the
fields including a save button etc. Recently we had an SSB fieldday and
I used some Windows program for logging. That was really convenient and
worked pretty well - without clicking. We should also have such an
option. Context specific checks would also be useful.

Post by Andy Stewart
For example, in a 6m contest, the exchange might be callsign, signal
report, and grid locator, which is challenging to do with the current
software.

Right. The software should lead you through the QSO during a contest.

Post by Andy Stewart
I am interested in your ideas. I'd like to find a way to maintain a
balance between the casual users of Xlog and those who would like the
tool to be more user friendly for contest logging.

Re-adding the date button and its mnemonic would be simple and could be
the default. So that a new field ordering can be done as an option. I
guess I will first work on a configurable order of the new QSO fields
and add a configurable save button.

BTW, is GTK-2 set or would migrating to GTK-3 be okay? I can live with
both.


Salam-Shalom,

Werner

[Werner Koch]

Post by Werner Koch
That is also my idea. I am thinking about a configurable order of the
fields including a save button etc. Recently we had an SSB fieldday and

Meanwhile I implemented a configurable order of fields in the QSO
frame. The known field names are:

- time (actually date and time entry)
- call
- band
- mode
- txrst
- rxrst
- qslbox
- awards
- power
- name
- qth
- locator
- unknown1
- unknown2
- remarks

and they also define the original order. To use the order I had in my
screenshot one would put

qsofieldorder=band mode time

into the mainwibdow section or use the preference dialog to set them
(restart required, though). All fields which are not listed in
qsofieldorder are added after them in the standard order. Adding
support for a save button should be easy.

BTW, is a specification for the flog format available?


Shalom-Salam,

Werner

[Andy Stewart]

Post by Werner Koch
Hello Andy,

Hi Werner,

Post by Werner Koch

Post by Andy Stewart

Post by Werner Koch
1. Change the color of a new callsign when it has been worked.

The above seems like it would be a relatively simple, but useful addition.

I just fixed a little bug.

:-)

Post by Werner Koch

Post by Andy Stewart

Post by Werner Koch
2. Just one button to set date and UTC to the current time.
It does not make sense to be able to set the current time

I'm curious...did you remove a button from the GUI? Do you have a
screenshot?

https://eifzilla.de/scratch/xlog-1.png
I removed the date button because the UTC button also fills in the
date. This also shows the reordered fields.
It might be better to have an in-entry button on the right side to fill
in the UTC and for contests it should be done anyway at save-time.

Post by Andy Stewart
I have a friend who has wished for a) a better/different order in the
New QSO frame, or b) the ability to add/delete those boxes at will,
for different contests, and c) the ability to enter a QSO *without*
needing the mouse. My friend's chief complaint is that tabbing over
unused info boxes is error prone and should be unnecessary. Toward
that end, I'm curious about your changes.

That is also my idea. I am thinking about a configurable order of the
fields including a save button etc. Recently we had an SSB fieldday and
I used some Windows program for logging. That was really convenient and
worked pretty well - without clicking. We should also have such an
option. Context specific checks would also be useful.

If there is a way to rearrage/omit the fields, in a user customizable
way, I think that will meet the needs of the majority of users.

Post by Werner Koch

Post by Andy Stewart
For example, in a 6m contest, the exchange might be callsign, signal
report, and grid locator, which is challenging to do with the current
software.

Right. The software should lead you through the QSO during a contest.

Post by Andy Stewart
I am interested in your ideas. I'd like to find a way to maintain a
balance between the casual users of Xlog and those who would like the
tool to be more user friendly for contest logging.

Re-adding the date button and its mnemonic would be simple and could be
the default. So that a new field ordering can be done as an option. I
guess I will first work on a configurable order of the new QSO fields
and add a configurable save button.
BTW, is GTK-2 set or would migrating to GTK-3 be okay? I can live with
both.

I am OK with migrating to GTK-3. If this happens, my conservative
proposal for the Savannah repository is as follows:

a) modify the code to use GTK-3 without addition or loss of functionality

b) start adding features one at a time with thorough testing

c) release a new version when it is ready

Regarding your other email, kudos on implementing a configurable order
of fields. I'm wondering if this ordering is global (for all *.xlog
files), or if it can be different for each log?

Post by Werner Koch
Salam-Shalom,
Werner

Thanks, Werner, and 73,

Andy

[Werner Koch]

Post by Andy Stewart
If there is a way to rearrage/omit the fields, in a user customizable
way, I think that will meet the needs of the majority of users.

Okay.

Post by Andy Stewart
I am OK with migrating to GTK-3. If this happens, my conservative

I agree to this proposal. However, I have no immediate plans to do
that. I have one other GTK+ project (GPA) which still uses GTK+-2 and
it still works nicely. However, in case Linux distributions start to
drop Gtk+-2 we should be prepared to move on.

Post by Andy Stewart
Regarding your other email, kudos on implementing a configurable order
of fields. I'm wondering if this ordering is global (for all *.xlog
files), or if it can be different for each log?

The ordering is currently global (in xlog.cfg) but I consider this more
as a default for new log files. It might be useful to have profiles
which can be used for more than just field orders, for example a profile
with setting and special features useful for a certain contest.
Associating such profiles with a log file would also be very useful. I
only wonder on how to put such meta data into the flog (?) log files
xlog works with. Any ideas?


Salam-Shalom,

Werner

[Werner Koch]

Post by Werner Koch
Associating such profiles with a log file would also be very useful. I
only wonder on how to put such meta data into the flog (?) log files
xlog works with. Any ideas?

Maybe it is easier to write a separate config file for each log file iff
that log file is in contest mode. To avoid disturbing the current
layout and behaviour I will next implement such a contest flag; a flag
allows to enable features like coloring the callsign etc.

If someone is interested in a tarball for testing, just let me know.


Shalom-Salam,

Werner


p.s.
These are my current changes:
* Make the callsign entry bold and set focus to it.
* Revamp the on_callentry_unfocus func to avoid memleaks.
* Revamp the large on_mainwindow_keypress function.
* Avoid memory leak in on_abutton_clicked.
* Fix insert-text handler for new_text_length == -1.
* Adapt colors from N1MM
* Check fields and show error message on save button click.
* Validate the callsign when using the new save button.
* No more restart for changed qso field order and "!*" special.
* Simplify the create QSO frame functions.
* Use a separate endtime qso field order item.
* Allow to globally disable QSO frame fields using the qsofieldsorder.
* Allow for a "save" button the QSO frame
* Initial support to configure the order of QSO frame fields.
* Use enums instead of numbers for QSO frame field numbers.
* Remove po/*gmo files and xlog.pot from the repo.
* Fix the create new log prompt.
* Reorganize code to create main window.
* Fix greening of new callsigns.
* Change the order of fields in the QSO frame
* Change the color of a new callsign when it has been worked.
* Add an invisible widget to track the "new QSO" state.
* Just one button to set date and UTC to the current time.
* Reorganize parts of the main window code.
* Allow xloggettime to optionally return the date.

[Andy Stewart]

Post by Werner Koch

Post by Werner Koch
Associating such profiles with a log file would also be very useful. I
only wonder on how to put such meta data into the flog (?) log files
xlog works with. Any ideas?

Maybe it is easier to write a separate config file for each log file iff
that log file is in contest mode. To avoid disturbing the current
layout and behaviour I will next implement such a contest flag; a flag
allows to enable features like coloring the callsign etc.
If someone is interested in a tarball for testing, just let me know.
Shalom-Salam,
Werner

Hi Werner,

I agree that there is no immediate need to modify the code to be GTK-3
compliant.

I am interested in a tarball and a screenshot of the main window.

Thanks, and 73,

Andy

[Werner Koch]

Post by Andy Stewart
I am interested in a tarball and a screenshot of the main window.

There are not many visible changes yet, give me some time to add
something useful. I implemented a global contest flag which is
currently not in the preferences which allows to swicth between two
different sort order and will also be used to speed up entering a new
QSO.

Something different: I don't quite understand the design of the flog
format for logs. Is it really needed to have fixed length fields? I
can imagine a more compact format which could easily be detected and
used as an flog2 format, for example:

NR:CALL:TIME:TXRST:RXRST:NAME:REMARK
1:DD9JN:20181115T173701:59 348:59 001:Werner:
2:KB1OIQ:20181115T173751:59 349:59 002:Any:xlog maintainer%0Asecond line:

fields are delimited by colons and percent escaping is used to quote the
colon and other characters (like the LF in the remark). The percent
escaping would be very rarely used because % is not used in standard
QSOs. This also means you can easily process such files like:

awk -F: {print $2} | sort | uniq

to get a sorted list of call signs. The names of the fields could also
be dropped and a standard order be defined. Having empty fields would
be just a colon. And well, the time format could also be changed to an
easy sortable one, like above.



Shalom-Salam,

Werner

[Elwood Downey]

Regarding a log format, why not just ise ADIF?

WB0OEW


Message: 1

Date: Fri, 16 Nov 2018 09:39:38 +0100
Subject: Re: [Xlog-discussion] A few xlog patches
Content-Type: text/plain; charset="us-ascii"

Post by Andy Stewart
I am interested in a tarball and a screenshot of the main window.

There are not many visible changes yet, give me some time to add
something useful. I implemented a global contest flag which is
currently not in the preferences which allows to swicth between two
different sort order and will also be used to speed up entering a new
QSO.
Something different: I don't quite understand the design of the flog
format for logs. Is it really needed to have fixed length fields? I
can imagine a more compact format which could easily be detected and
NR:CALL:TIME:TXRST:RXRST:NAME:REMARK
fields are delimited by colons and percent escaping is used to quote the
colon and other characters (like the LF in the remark). The percent
escaping would be very rarely used because % is not used in standard
awk -F: {print $2} | sort | uniq
to get a sorted list of call signs. The names of the fields could also
be dropped and a standard order be defined. Having empty fields would
be just a colon. And well, the time format could also be changed to an
easy sortable one, like above.
Shalom-Salam,
Werner

[Werner Koch]

Post by Elwood Downey
Regarding a log format, why not just ise ADIF?

Because ADIF is not easy to parse with standard Unix tools. This mostly
is because it uses an tag-length-value system. It is fine as a data
exchange protocol but hard to work with unless you use dedicated tools.

Most other log programs are using SQL databases which have a very
expressive query language and cal also be used concurrently. From my
understanding xlog shall be an easy to use and single user log program.
Thus I doubt that a complicated log on-disk format makes sense. The
current flog format is okay but somewhat limited in extensibility and
you need to take care if you want to change it with an editor.


Salam-Shalom,

Werner

[Elwood Downey]

Post by Werner Koch
Because ADIF is not easy to parse with standard Unix tools.

I could not resist a challenge like this. Here is a perl script that scans
an ADIF file and lists any given columns in CSV format. Enjoy!



#!/usr/bin/perl -w
# print each desired field as a CSV list from each record of the ADIF file
on stdin.
# ADIF specification at http://www.adif.org/adif.html
# This software is in the public domain.
# 20181117: first version

use strict;
use warnings;

# print usage unless at least one arg
if (@ARGV < 1) {
$0 =~ s:.*/::;
print STDERR "Purpose: list fields from ADIF file records in CSV
format\n";
print STDERR "Usage: $0 field1 field2 ... < adif_file\n";
exit 1;
}

# local variables
my $saweoh; #
EOH> flag
my @csv; #
columns in one report line

# print column headings
print "# " . join (",", @ARGV) . "\n";

# scan stdin
while (<STDIN>) {
foreach (split (/</)) { #
split at each <
if (/eoh>/i) { $saweoh = 1; next;} #
check for EOH
if (!$saweoh) {next;} #
skip until find EOH
if (/eor>/i) { #
check for EOR
my $sep = ""; #
csv separator starts blank
foreach (@csv) { #
print each column
$_ = "" unless (defined($_)); #
beware missing fields
print "$sep$_"; #
print column preceded with sep
$sep = ","; #
now use ,
}
print "\n"; #
EOL
@csv = (); #
reset report line
next; #
next field
}
my ($field, $len, $value) = /([^:]+):([\d]+)[^>]*>(.*)/; #
crack
next if (!$field or !$len or !$value); #
skip if empty
my ($column) = grep { $ARGV[$_] eq $field } (0 .. @ARGV-1); #
find desired column for field
next unless (defined($column) and $column >= 0); #
skip if not wanted
$csv[$column] = sprintf "%*.*s", $len, $len, $value; #
add at column at spec length
}
}

# good
exit 0;