Re: TLF, open source contest logging SW, and contest logging SW future

[Nate Bargmann]

Beware that I've been watching this space for nearly 25 years and I've
developed a certain skepticism/cynicism.  Unavoidable, I guess.

* On 2022 15 Nov 05:59 -0600, Alan Dove wrote:
> Hey, folks:
> 
> I agree that the current state of logging software - on all platforms -
> is pretty stale. This business of having bespoke platform-restricted
> programs, each with its own peculiar ways of doing things, feels very
> dated now. The plethora of ham logging applications in development
> suggests a lot of other people feel the same. Unfortunately, almost all
> of them are one-person efforts that seem to get off to a strong start,
> then languish.

I think the unquestioned leader these days is N1MM+.  I've not looked at
it for a couple of years but the breadth and depth of events it supports
likely dwarfs any current project by an order of magnitude or more.
Eclipsing it would be a Herculean task; equaling it would astounding.
Tom has a dedicated group of developers that churn out updates at an
incredible rate: https://n1mmwp.hamdocs.com/downloads/update-history/

I'll be honest and say that it will take untold hours and dedication to
equal it.  The only thing that N1MM+ has against it is that is locked
into MS Windows and that doesn't appear to be changing any time soon.

> Rather than having individual developers dive right into coding more
> soon-to-be-abandoned loggers from scratch, I think what needs to happen
> is for a group of code-literate hams to come together and decide on a
> general approach, then pursue it together. I've been thinking about two
> potential strategies, each with distinct strengths and weaknesses. 
> 
> Because I've been learning game coding recently, I've thought about
> building a logger in Godot, the open source game engine (
> https://godotengine.org/ ). As a game engine, Godot has a slew of
> built-in functions for displaying information, and this could produce a
> logger that looks really cool and is fun to use. Cross-platform
> compilation is built into the engine, so releasing packages for
> Windows, Mac, Linux, Android, iOS and web should all be feasible. The
> main drawback to this approach is that I suspect the number of hams who
> are also into Godot is pretty small, so the developer pool might be
> kind of restricted. That said, Godot is not that hard to learn, and its
> internal scripting language is very much like Python.

That is intriguing, how approachable is it for hobbyists?  Its main Web
page promises a lot.  Certainly the ability to use various languages
would appear to offer opportunities to various developers.
Cross-platform is a definite win.

> The other strategy would be to build a logger in some Javascript-based
> web-like framework, either with Electron or as a progressive web app (
> https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps ).
> Everybody and their mother has some relevant coding skills in the
> underlying languages (HTML, CSS, Javascript), so there's a huge
> potential developer pool, and these sorts of applications are
> inherently cross-platform. I think the biggest challenges would
> probably be things like rig interfacing and possibly performance issues
> with logs containing huge numbers of QSOs.

JS has historically implied the use of a browser and browsers have
historically been very poor at maintaining focus of a text entry field.
It is a regular annoyance of mine to be typing into a browser window,
switching away to another application for whatever reason, switching
back and begin typing only to look and see that my keystrokes have
apparently been directed to /dev/null.  This has been an ongoing issue
since ever since I started using browsers!  This makes them completely
unacceptable for use as a contest logger which is also why I think this
approach has never caught on.

For efficient entry a logger needs to return focus to the field that was
in use before whatever action caused it lose focus and it needs to do
this every time without the operator having to intervene.  Even in
stand-alone apps this requires careful attention.  With browsers
seemingly breaking keyboard UI willy nilly over the decades, this is
unacceptable.

If such a JS app can be coded to run stand-alone then the goal is
possible.

As it is unlikely that MS will port .NET to Linux such that it will run
on all distributions as well as on later versions of Windows, N1MM+
being multi-platform is a pipe dream.  Of the two approaches above the
Godot approach likely has the better chance of implementing a UI serious
contest operators can utilize.

> Until such a project gets underway, I think we'll just keep muddling
> through with the current mix of applications.

I think there will always be a variations of applications available due
to varying operator interests.  There will be operators who only want to
log and dupe and submit a Cabrillo log with no external device
interfacing.  At the other end are those who want the logger to control
every device in the shack (and then some) while they only enter the QSO
data.  My past experience with N1MM+, which is a few years dated by now,
allowed for both approaches.  The downside is that it requires MS
Windows with a working installation of .NET and it is always in GUI
mode.  It does not serve those who would like a simple TUI.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

signature.asc
Description: PGP signature