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