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
