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
