A few xlog patches

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few xlog patches

Andy Stewart-2
On 11/5/18 2:32 AM, Werner Koch wrote:
> 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.

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

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

>
> 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?

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

> 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

--
Andy Stewart (KB1OIQ)
Founder:   Worcester Linux Users' Group
Founder:   Chelmsford Linux Meetup Group
President: PART of Westford, MA (WB1GOF)

_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion
Reply | Threaded
Open this post in threaded view
|

Re: A few xlog patches

Werner Koch
Hello Andy,

On Tue,  6 Nov 2018 05:59, [hidden email] said:

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

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

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

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

> 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

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few xlog patches

Werner Koch
On Tue,  6 Nov 2018 10:17, [hidden email] said:

> 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


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few xlog patches

Andy Stewart-2
In reply to this post by Werner Koch
On 11/6/18 4:17 AM, Werner Koch wrote:
> Hello Andy,

Hi Werner,

>
> On Tue,  6 Nov 2018 05:59, [hidden email] said:
>
>>> 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.

:-)

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


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

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

>
>
> Salam-Shalom,
>
>     Werner
>

Thanks, Werner, and 73,

Andy

--
Andy Stewart (KB1OIQ)
Founder:   Worcester Linux Users' Group
Founder:   Chelmsford Linux Meetup Group
President: PART of Westford, MA (WB1GOF)

_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion
Reply | Threaded
Open this post in threaded view
|

Re: A few xlog patches

Werner Koch
On Wed,  7 Nov 2018 02:44, [hidden email] said:

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

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

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.

> 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

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few xlog patches

Werner Koch
On Thu,  8 Nov 2018 12:32, [hidden email] said:

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

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few xlog patches

Andy Stewart-2
On 11/11/18 2:18 PM, Werner Koch wrote:

> On Thu,  8 Nov 2018 12:32, [hidden email] said:
>
>> 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

--
Andy Stewart (KB1OIQ)
Founder:   Worcester Linux Users' Group
Founder:   Chelmsford Linux Meetup Group
President: PART of Westford, MA (WB1GOF)

_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion
Reply | Threaded
Open this post in threaded view
|

Re: A few xlog patches

Werner Koch
On Sun, 11 Nov 2018 23:11, [hidden email] said:

> 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

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few xlog patches

Elwood Downey
In reply to this post by Werner Koch
Regarding a log format, why not just ise ADIF?

WB0OEW


Message: 1
Date: Fri, 16 Nov 2018 09:39:38 +0100
From: Werner Koch <[hidden email]>
To: Andy Stewart <[hidden email]>
Cc: [hidden email]
Subject: Re: [Xlog-discussion] A few xlog patches
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="us-ascii"

On Sun, 11 Nov 2018 23:11, [hidden email] said:

> 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


_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion
Reply | Threaded
Open this post in threaded view
|

Re: A few xlog patches

Werner Koch
On Sat, 17 Nov 2018 01:20, [hidden email] said:
> 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

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few xlog patches

Elwood Downey


On Sat, Nov 17, 2018 at 2:50 AM Werner Koch <[hidden email]> wrote:
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;




 

_______________________________________________
Xlog-discussion mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/xlog-discussion