Re: What is the tlf future?

[Nate Bargmann]

* On 2022 14 Oct 10:05 -0500, Alan Dove wrote:
> Hey, folks:
> 
> The biggest barrier I see to wider Linux use in the ham shack is that
> the two most important pieces of software for hams, a general logger
> and a contest logger, are only available in single-platform versions
> that haven't drawn very large developer communities. Essentially,
> there's CQRLog for general logging, and about 1.5 usable contest
> loggers that all run in console windows. 
> 
> None of these applications are available on Windows or Mac, so right
> away the pool of potential developers is only that tiny sliver of the
> Venn diagram where ham radio operators, qualified software developers,
> and Linux aficionados overlap. For CQRLog, the developer pool gets even
> smaller because it's in Pascal. And don't @ me with "Pascal is elegant"
> and so forth; I'm just referring to the objective fact that it's far
> less popular than, say, C++, and therefore has fewer programmers
> available to work on it.

Alan, these are all good points and I'm not going to dispute them.  I
will say that all other loggers are single platform as well.  N1MM+ is
tied to MS Windows being written in .Net.  The Mac loggers would likely
be the easiest to cross-platform to Linux but so far I've not seen that
effort either.  So no matter what application one chooses, you're locked
into the OS silo that choice runs on.

> Since these applications are all Free, the developers who do work on
> them generally have day jobs and other commitments. So we have a tiny
> pool of people who are even qualified to work on these programs, and
> they're all working part-time. Of course progress is slow. 

N1MM+ is available free of charge.  Apparently there are enough
contesters fluent in .Net to continue driving its development.  Given
that .Net is very much a proprietary framework of Microsoft it is a bit
astonishing that N1MM+ has gained such developer mind share.

> Until someone develops a cross-platform logger using a popular
> framework, and manages to attract a critical mass of developers to it,
> this won't change. Consider Fldigi, which runs perfectly on Linux and
> gets maniacally frequent updates. That's all because it's drawn a large
> group of developers and users, the overwhelming majority of whom are
> using Windows in the shack.

Fldigi is emblematic of many cross-platform application as it started on
Linux and built out from there.  There are many other examples, too many
to list, actually, that became cross-platform in this manner.
Meanwhile, the number of applications that started on MS Windows and
became cross-platform to Linux is vanishingly small. My point here is
waiting for a popular Windows application to become cross-platform to
Linux has been a long wait and the world will be waiting for a long time
to come.

Having dabbled with porting a GTK program from GTK 2 to GTK 3 I have
come to appreciate that GUI toolkits are not not for the faint of heart.
Then, what I have seen of GTK 4, it is basically unsuitable for any
application that needs a UI that goes beyond the relatively simple UI
dictated by GNOME.  So, for a general cross-platform GUI toolkit there
are really just two choices that I am aware of, Qt and Fltk.  Both are
C++ libraries so writing code in C is pretty much out of the question
(perhaps I am wrong here) and so coding must happen in C++.  Is it
possible for a mortal hobbyist programmer to work in C++ effectively?
With its templates and other additions to its more recent standards, I
decided that my time was better spent in code much more simple.

For all its warts, NCurses is approachable by nearly anyone conversant
in C.  It is very low level and requires a fair amount of boilerplate in
the code to develop an effective TUI.  There are a couple of small
projects out there to develop TUI libraries with widgets and so on to
eliminate a lot of the boilerplate.  So far they don't seem to have
gotten much traction.

The code in TLF is difficult to understand and follow in part because of
NCurses calls scattered throughout the code.  Historically TLF has not
been implemented in an MVC design, as I understand MVC which may be
wrong.  Most programmer hams have probably taken a look at the TLF code
base and been scarred for life!  No, it's not that bad but it is
typical of hobbyist projects where the primary object is writing code
and adding features.  While I have contributed to TLF I am just a small
contributor compared to Tom, Zoli, and others who understand it much
better than me.

All that said, TLF fills a niche no GUI logger ever can.  GUI loggers
offer eye candy that TLF cannot.  I am not active in all that many
events so TLF fills my needs these days.  I can say that Tom and Zoli,
et. al. do consider requests and bug reports and act on them.

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