e915527 
nigelfenton
Nigel Fenton
ShackLog is now ShackBook
If you already use this program, read this first — but you do not need to do anything.
A UK amateur radio logging program has used the name ShackLog since at least 2005, holds shacklog.co.uk and shacklog.com, and is listed on DXZone. There is no connection between the two projects. Continuing under that name would have been confusing for operators and unfair to the people who had it first, so this project moved.
Your logbooks come with you, automatically. The first time you run this version, your existing data directory is copied — not moved — from …/G0JKN/ShackLog/ to …/G0JKN/ShackBook/, and the program tells you it has done so. Your originals are left exactly where they were; delete them by hand once you are satisfied everything arrived. If you have already started logging under the new name, nothing is overwritten.
This was tested against a real 16,538-QSO logbook before release, not only in unit tests.
Two things worth knowing:
- ADIF and Cabrillo exports now carry
ShackBookas the program ID. Logs you exported before today keepShackLog, which is correct — that is what produced them. - The Windows installer upgrades in place. Its application ID is deliberately unchanged, so this replaces your existing install rather than sitting alongside it.
Session Map
Maps → Session Map… — where did tonight's QSOs actually go?
The Grid Map answers what have I ever worked. After an evening at the radio the more interesting question is where the signal got out tonight: which bands were open, which direction was working, whether that new antenna changed the footprint. Until now the only way to see that was to leave the program for PSKReporter, which shows reception reports rather than logged QSOs and only for digital modes.
Contacts are plotted at their grid square with a great-circle path from your own grid, coloured by band so a multi-band evening reads as separate footprints. Previous / Next walk back through earlier sessions.
A session is derived rather than stored: a gap of more than two hours starts a new one. That keeps an evening which crosses midnight UTC in one piece — which a plain date filter gets wrong, and which lands mid-evening for US operators — while still separating an afternoon session from an evening one.
The paths are real great circles, not straight lines on the map. Maryland to Japan drawn straight runs across the Pacific; the actual path goes over the pole, and drawing the wrong one would misrepresent the very thing the map exists to show.
It tells you what it could not place. QSOs without a usable grid square cannot be plotted, and the window says how many rather than quietly dropping them — for example "13 QSOs | 11 plotted | 2 without a usable grid — not shown". In a real log that is a meaningful fraction, since hand-logged SSB contacts often carry no grid at all.
QSO Party mode
Tools → QSO Party… — worked/needed counties, and what is on.
One window rather than two, because during a party "what is running" and "which counties do I still need for it" are the same question. The party picker preselects whatever is running today, so opening it mid-event lands on the right one without a click.
The worked/needed table is the part that changes how you operate. It turns "have I got Calvert yet?" from a memory question into a glance. Needed counties are listed, not merely counted — a count tells you how far there is to go, a list tells you what to chase — and the list is selectable so it pastes into a spot or a club chat.
Backing it is a bundled US county reference list: 3,235 counties from the US Census 2020 FIPS data, covering all 50 states plus DC, Puerto Rico, the US Virgin Islands, Guam, American Samoa and the Northern Mariana Islands. It includes the awkward cases — Virginia's 38 independent cities, Louisiana's 64 parishes, Alaska's boroughs and census areas, Puerto Rico's municipios.
It is bundled rather than fetched for a reason: the machine that most needs this is often the one at a field site with no internet.
The matcher is strict, and says so when it cannot place a value. On a real logbook it immediately surfaced nine genuine logging errors — FL,Alameda (Alameda is California), FL,Ponce and FL,Aibonito (both Puerto Rico), FL,Pinal (Arizona). Silently ignoring those would have turned nine data-entry mistakes into a quietly wrong needed count.
A contest calendar shows what is on now and coming up. It stores recurrence rules rather than dates — "the second full weekend of August" — and computes the dates for whatever year you ask about. A bundled table of dates would be silently stale the following year, on precisely the machine least able to refresh it.
Notes
The bundled contest definitions each carry their own provenance marker. Every one currently reads UNCONFIRMED: the exchange shapes are the common county-party form and are probably right, but nobody has checked them line by line against each sponsor's published rules. They are fine for chasing counties, where being wrong costs a mis-labelled column — check before relying on one for a submitted log.
The calendar's recurrence rules carry the same caveat. A wrong rule shows you the wrong weekend, which is annoying but visible.
Downloads below: Windows installer and zip, Linux AppImage, macOS DMG.
Full commit list
What's Changed
- feat(counties): bundle a US county reference list so needed can be shown (#5) by @nigelfenton in #6
- feat(contest): contest definitions and a worked/needed county table (#4) by @nigelfenton in #8
- feat(maps): Session Map — where did tonight's QSOs actually go? (#3) by @nigelfenton in #7
Full Changelog: v0.6.0...v0.7.0