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

[Marcin SP6MI]

Hi,
Can you share link to your TUI python code? 

And it's hard to compare bare C code with modern Python code, in such case 
number of lines of code is not a good factor. Entry level for developers, code 
quality, and complexity, this is what is important. Or even user friendly 
interface is more important

All the best
Marcin SP6MI
73!


Wysłano z bezpiecznej poczty e-mail Proton Mail.

------- Original Message -------
wtorek, 15 listopada 2022 06:23, Drew Arnett <arnett.drew@gmail.com> napisał(a):


> I think asking what is in the future is a great question.
> 
> Is it continued innovation and features for the top contesters? You
> know, the ones who need 2 or more radios to keep from getting bored
> during a contest and are doing 400+ QSOs/hour. Is there room for
> innovation for more average contesters like me? Is it some specific
> new feature or modification to tlf?
> 
> I think it would be very interesting, and perhaps challenging, to try
> to compile a document describing all of the features everyone would
> want, even when those conflict. (It's software, and, within reason, I
> think it is good to accommodate different preferences different people
> have. Sometimes this can be done well in a single program; sometimes
> this means having several different programs. The open source
> ecosystem is a good example.) Writing a second product specification
> document from that would be interesting as well. Not going to tackle
> this myself, but would be fascinating reading.
> 
> For me, the future of contest logging software is having an open
> interoperability specification for networking contest loggers. I
> think this is the highest priority. If we had it, then when operators
> get together for multi-op contesting (from Field Day or CQ WW),
> everyone can bring their own SW to use with whatever customization it
> has that suits their preferences. And can bring whatever operating
> system compute device as well.
> 
> The src directory for tlf (in debian stable) looks to be about 35 KLOC
> (kilo lines of code). I wanted to find out how much python it would
> take to write a (like tlf) TUI contest logger. (And I wanted a
> vehicle for experimentation.) 1 KLOC was enough and not a lot of
> hours were required, either. This did not have assistance (spotting
> network), live score tabulation, mults needed, bandmap (that is no
> realtime analysis or guidance). This did have cwdaemon and rigctld
> client capability, serial number generation, highlighting when fields
> have valid content, country file, super partial, and call history
> support, dupe checking, macros, and enter-send-mode. The TUI API is
> so similar to a GUI API that porting to a GUI like Qt5 would be easy.
> And the TUI and python code should run cross platform as is. Yes, a
> large portion of the code is UI and UX.
> 
> I think the only limitation is imagination or that requirements
> gathering and product specification exercise. (Networking is the only
> feature missing to either have my friends use my software or for my
> software to interoperate with N1MM or whatever they use when we get
> together for multi-multi contesting several times a year.) But still,
> I'd like to see an open interoperability specification for networking
> contest loggers even before an elaborate specifications doc.
> 
> I'd be very interested to read what others think about the future for
> tlf and contest loggers in general on a large or small scale. And I"d
> find it very interesting to read about features and functionality
> people want or just want to try out.
> 
> Fun stuff.
> 
> Drew
> n7da