v0.03

The NetBSD, DragonFly BSD, Haiku and OpenBSD builds compile again; FreeBSD riscv64 waits for packages

• wena3 log: NetBSD amd64 and arm64, DragonFly BSD and Haiku stopped on
  server/executable_path.c: their GCC rejects an if with more statements
  after it on a line of its own (-Werror=misleading-indentation), which
  clang - and so the header check of v0.02 - accepts. Those lines now hold one
  statement each. tests/test_bsd_sources.py also compiles every desktop
  source with GCC 13 on NetBSD's headers (the host's GCC, or the pinned
  gcc:13 image), reproduced the error at the same line before the fix, and
  rejects a probe of the pattern.
• OpenBSD amd64 and arm64 stopped unpacking SDL2: OpenBSD's tar has no
  --strip-components. scripts/extract_archive.py unpacks the pinned
  archives without their top directory on every system, keeping modes and
  links and refusing entries or links that leave the destination
  (tests/test_extract_archive.py, suite extract-archive).
• FreeBSD riscv64 is planned again: FreeBSD publishes no riscv64 packages for
  14 or 15, so its virtual machine has no Python, make or X11 to build with.
  Cross-compiling it from Linux is the way there.
• Verified here: GCC 13 on NetBSD 10.1's headers reproduced the release
  run's error at executable_path.c:31 and passes after the fix; all desktop
  sources compile with clang for FreeBSD, OpenBSD and NetBSD and with GCC for
  NetBSD; the pinned SDL2 and llvm-mingw archives unpack and run. The BSD and
  Haiku builds themselves are verified by the next release run.

Thanks to xet7.

The AROS x86-64 release file is wena-aros-amd64, named for its CPU as every other file is

• wena-aros-x86 was an x86-64 file (ELF 64-bit LSB relocatable, x86-64),
  while "x86" names 32-bit x86 everywhere else. The target is now
  aros-amd64, its file wena-aros-amd64, as wena-linux-amd64 and
  wena-windows-amd64.exe are.
• The release check takes the CPU from the name: an aros-amd64 file must
  be a 64-bit x86-64 relocatable ELF and an aros-i386 one a 32-bit i386
  one, and an AROS name with any other CPU is refused. The target catalog
  allows no target ending in the ambiguous -x86.
• config/targets.tsv lists AROS per CPU: aros-i386 for the 32-bit ABIv0
  line of deadwood2/AROS (planned until its build is in the release
  workflow), AROS on m68k running wena-amigaos-m68k, and AROS on ARM having
  no published toolchain or SDK to build with.

Thanks to xet7.

The desktop opens again after it was closed normally

• Run, and a double-click on the desktop, said "Unable to open the local Wena
  desktop" for a board that was there. The startup check that an actor or
  board named by mistake writes nothing opened the file read-only, and a
  read-only handle cannot read a WAL database whose -wal file a clean exit
  removed ("unable to open database file"). So every launch after a normal
  quit failed, and only a launch after a crash worked.
• The check now opens the existing file read-write without creating it, with
  PRAGMA query_only=ON: a missing file still fails, and nothing can be
  written. The debug log names which check failed and SQLite's reason.
• tests/test_desktop.sh closes a WAL workspace cleanly (no -wal or -shm
  file) and opens it, and checks that an unknown actor there still changes
  nothing. With the read-only handle back, it fails as Run did.

Thanks to xet7.

The desktop board looks and works like WeKan's: its colors, fonts, header, lists, cards and menus

• Measured from WeKan, not chosen by eye: tools/wekan-ui/capture.e2e.js
  runs in WeKan's Playwright suite against a running WeKan and records each
  state of a seeded board (the board, list and swimlane menus, Add Card, the
  sidebar, card details and its menu) with every visible control's text,
  tooltip, icon, place and colors. tools/wekan-ui/pin.py pins them in
  tests/fixtures/wekan-ui.
• client/components/common/wekan_look.c holds WeKan's colors (the
  #2980b9 header, #dedede canvas, #e4e4e4 list headers, white
  minicards with #4d4d4d text, white popups with gray title bars, #f7f7f7
  panels, the red #ce1414 of a list over its WIP limit), its fonts (Roboto
  and Roboto Bold, now embedded with its provenance, at WeKan's 12 to 19 px)
  and its Font Awesome icons as vectors. The Nuklear theme uses the same
  palette.
• The same controls in the same places, named as WeKan names them: the header
  with the board title, Filter, the user and the sidebar toggle; swimlane
  headers with their caret and Swimlane Actions; list headers with Collapse,
  Add Card to Top of List, Add List and List Actions, and a long title that
  wraps; minicards with their caret and Card Actions; "+ Add Card" under each
  list; collapsed lists as a narrow strip with the title stacked; WeKan's
  popup menus for lists, swimlanes and the user, the Filter panel and Change
  Language.
• Dragging works as in WeKan: the whole minicard, list header or swimlane bar
  is the handle, and a press and release without moving is a click that opens
  the card or edits the title. The swimlane resize handle is WeKan's 10 px
  bar, shown when hovered.
• Every control is recorded with its WeKan name and place each frame, which
  is what tests click. --screenshot FILE saves the last frame as a BMP, to
  set beside WeKan's captured screenshots.
  An icon's tooltip is drawn at window level: opened from inside a header
  row, it broke the frame, so nothing after the hovered icon was drawn.
• tests/test_wekan_ui_parity.py (suite wekan-ui-parity) checks every
  Wena color against WeKan's capture, and the WIP color against WeKan's
  stylesheet when the WeKan checkout is next to Wena. The board, list, card,
  filter, theme, SVG, collapse and swimlane-resize suites now click WeKan's
  control names and check WeKan's colors, including the hovered tooltip, the
  sidebar opening below the header, and a missing selection marking nothing.

Thanks to xet7.