rouggy
ae06495f91
A new county and a new park both drew --success, so the two were the same green in the cluster list and, since the band map copied it, in the band map too. County takes violet; POTA keeps green, the association being worth something. Violet is a chart hue rather than a semantic token because every token was already spoken for: red, orange and yellow are the entity statuses, blue is "callsign already worked", green is now POTA. It is defined in both the light and dark chart groups, so all eleven themes have it. Changed in BOTH panels at once — separating them in one place would have left the two views contradicting each other about the same fact, which is worse than sharing a colour. To make that impossible to get wrong again, the marker definitions move to lib/spotMarkers: key, colour and label in one table that the cluster list and the band map both read. That table is what a per-marker colour setting will drive, which is why it is a table and not three constants. The band map deliberately shows three of the four markers. A new PREFIX stays a cluster-list badge: the pill is 22 px tall and a fourth segment on its strip turns it into a colour code nobody reads at a glance.
42 lines
2.1 KiB
TypeScript
42 lines
2.1 KiB
TypeScript
// The "extra" spot markers — the ones ORTHOGONAL to the entity status.
|
|
//
|
|
// A spot's entity status (new DXCC / new band / new slot / worked) answers one
|
|
// question. These answer others that can be true at the same time: the park is
|
|
// new even if the entity is worked, the county is new even if the band is not.
|
|
// Both the DX-cluster list and the band map show them, and they have to agree —
|
|
// the same fact must not be green in one panel and violet in the next, so the
|
|
// colours live HERE and nowhere else. This is also the table a per-marker colour
|
|
// setting will drive, which is why it is a table rather than three constants.
|
|
//
|
|
// Colour choices:
|
|
// POTA green — parks; the association is worth keeping
|
|
// county violet — a chart hue, because every semantic token was already
|
|
// spoken for: red, orange and yellow are the entity
|
|
// statuses, blue is "callsign worked", green is POTA
|
|
// worked blue — matches the WKD-CALL badge the cluster list has always used
|
|
// prefix yellow — unchanged
|
|
export type SpotMarkerKey = 'new_pota' | 'new_county' | 'new_pfx' | 'worked_call';
|
|
|
|
export type SpotMarker = {
|
|
key: SpotMarkerKey;
|
|
colour: string; // a CSS colour — a var() reference, so it follows the theme
|
|
labelKey: string; // i18n key, short form (badge / legend)
|
|
};
|
|
|
|
// Order is the display order, in both panels.
|
|
export const SPOT_MARKERS: SpotMarker[] = [
|
|
{ key: 'new_pota', colour: 'var(--success)', labelKey: 'clg2.newPota' },
|
|
{ key: 'new_county', colour: 'var(--chart-5)', labelKey: 'clg2.newCounty' },
|
|
{ key: 'new_pfx', colour: 'var(--caution)', labelKey: 'clg2.newPfx' },
|
|
{ key: 'worked_call', colour: 'var(--info)', labelKey: 'clg2.wkdCall' },
|
|
];
|
|
|
|
export const markerColour = (key: SpotMarkerKey): string =>
|
|
SPOT_MARKERS.find((m) => m.key === key)?.colour ?? 'var(--muted-foreground)';
|
|
|
|
// activeMarkers returns the markers set on a status entry, in display order.
|
|
export function activeMarkers(e: Record<string, unknown> | undefined): SpotMarker[] {
|
|
if (!e) return [];
|
|
return SPOT_MARKERS.filter((m) => !!e[m.key]);
|
|
}
|