v0.09

AROS x86 32-bit (ABIv0) and ARM 64-bit builds: wena-aros-i386 and wena-aros-arm64

• AROS runs on more CPUs than x86-64, and Wena is now built for every one
  that has a published cross-compiler and SDK:
  • wena-aros-i386: the 32-bit ABIv0 line of deadwood2/AROS that AROS
    One and the other i386 distributions run. It was in the catalog as
    planned.
  • wena-aros-arm64: AROS's AArch64 port (raspi-aarch64, Raspberry Pi
    3/4/5).
• Both build in BlitterStudio's AROS cross-compiler images
  (midwan/aros-compiler:i386-aros and :aarch64-aros), pinned by digest,
  with the same SDL2 2.32.10 and AROS port as wena-aros-amd64. They are
  two more Amiga jobs in the release workflow, and the release check takes
  each file only as a relocatable ELF of its own CPU.
• AROS on m68k runs wena-amigaos-m68k. AROS's 32-bit ARM (raspi-armhf)
  and PowerPC (sam440, Efika) ports have no published cross-compiler or SDK,
  so they are noted in config/targets.tsv rather than built.
• Those images carry a compiler and an SDK and little else, so what needed
  Python or patch in the container now happens on the host first
  (scripts/prepare_amiga_sources.py). It extracts SQLite for every Amiga
  target, and applies AROS's SDL2 port with Wena's edits (no OpenGL, SDL's
  own iconv, wcslen and wcscmp) for every AROS CPU. It stops when the port
  no longer has the lines it drops.
• Tests: prepare-amiga-sources checks the prepared tree, a missing archive
  and a changed port refused, and that the AROS container path needs no
  Python, patch or sed. amiga-desktop, target-catalog and
  build-entrypoints check the two images, the catalog, and a refused ELF
  of the wrong CPU.

Thanks to xet7.

AmigaOS 3 with RTG draws Wena inside its window, and the mouse points where it is drawn

• wena7 screenshot (FS-UAE, AmigaOS 3, 68040, RTG): Wena ran and showed
  All Boards, but the frame was drawn at the Workbench screen's top-left
  corner, over everything, and only a stray piece of it was in the "WeKan
  Native" window.
• The cause is in the pinned AmigaOS 3 SDL fork. The window is a
  GimmeZeroZero one on the Workbench screen, and its RastPort's BitMap is
  the screen's. The fork wrote that bitmap directly, or scaled into it, at
  (0, 0). Every update took the scaling path, because the window's outer
  Width, borders included, is always wider than the frame.
• scripts/patches/sdl2-amigaos3-window.patch, applied for both
  wena-amigaos-m68k and wena-amigaos-m68k-aga: a window on the
  Workbench screen gets its frame through WritePixelArray into its own
  RastPort, where the layers place and clip it, within the inner
  GZZWidth/GZZHeight. The direct video memory path stays for a window on
  its own screen.
• The mouse is from the window's GZZMouseX/GZZMouseY. An IntuiMessage's
  MouseX/Y count from the outer corner even in a GimmeZeroZero window, so
  clicks were off by the border sizes.
• A kept SDL build is reused only when it was made with the current
  patches.
• Checked for the same fault elsewhere: AROS's SDL port already draws
  through the window's RastPort at its border offset, and AmigaOS 4 uses
  the system's own SDL2, so neither needs it.
• Tests: amiga-desktop checks that the window patch applies to the
  pinned fork, alone and with the AGA patch. Its windowed path writes only
  through the window's RastPort, clipped to the inner area, and never locks,
  scales or reads the outer size. The mouse is the inner one, and both
  builds apply the patch before CMake.

Thanks to xet7.

WeKan's Admin Panel: People with Edit User, Login, Announcement and Version

• The member menu's Admin Panel (for an admin) opens WeKan's Admin Panel:
  its header's tabs (Settings, People, Attachments, Problems) and each tab's
  left menu, in WeKan's order. Wena's panes work; the rest are there,
  disabled. The house goes back to the board.
• People / People: WeKan's table of every user, by username: Edit,
  Username, Email, Admin, Active Person and Created at (WeKan's 'LLL'
  date). A disabled account is struck through, as WeKan's <s>. The Active
  icon (a check or a ban) toggles loginDisabled. Edit User edits
  Username, Full Name, Initials, Admin, Email and Active, with WeKan's taken
  and invalid errors. The last admin who can log in cannot be demoted or
  deactivated (WeKan's "there must be at least one admin"), and an admin
  who removes their own rights is taken back to the board.
• People / Login: WeKan's "Login: Allow" with Forgot password and
  Self-Registration, ticked when allowed and written at once to
  settings.disableForgotPassword and disableRegistration. Wena never
  makes WeKan's settings document: until WeKan has run on the files, the
  checkboxes cannot be changed and the pane says so.
• Settings / Announcement: WeKan's Active System-Wide Announcement and
  its message, saved to WeKan's announcement. It is made as WeKan's
  bootstrap makes it when there is none. Its version - WeKan's
  announcementVersion, a djb2 over the id, title and body in UTF-16
  units - and the user's profile.dismissedAnnouncementVersion are read
  and written, matching WeKan's own values.
• The board shows WeKan's announcement bar under the header (#f8ecbd,
  the message centred, a close cross) while the announcement is on and the
  user has not dismissed this text. Closing it writes
  profile.dismissedAnnouncementVersion, as WeKan's dismissAnnouncement
  does, so a dismissal holds in both, and an edited announcement shows
  again.
• Settings / Version: what Wena runs on: the database file, SQLite, SDL,
  the platform, and the counts of people and boards.
• --show admin-version, admin-announcement, admin-people and
  admin-login capture the panes.
• Tests:
  • admin-panel: the tabs and panes, Wena's four enabled, the house,
    People's Active and Edit, Edit User's Save and close, Announcement's
    Save, Login's checkbox writing the flag the other way and doing nothing
    without WeKan's settings, a disabled pane falling back, and the date.
  • wekan-sync: People by username; the last-admin guard, with a
    disabled admin not counting; Announcement made, then changed;
    announcementVersion matching Node's for three texts, one with Finnish
    letters, an emoji and a dash; the dismissal round trip; Login refused
    without WeKan's settings and keeping its other fields.
  • amiga-aga now checks that every page that presents a frame also
    gives it to the AGA screen.

Thanks to xet7.

WeKan's member menu, with Edit Profile and Change Settings that save to the user's WeKan profile

• The menu under the user's name is WeKan's memberMenuPopup now, in its
  order and with its icons. It has two columns when one would run past the
  window. All Boards, Admin Panel (for an admin only), Edit Profile, Change
  Settings and Change Language work. The rest are there as WeKan has them,
  disabled until Wena does them.
• Edit Profile (editProfilePopup) edits Full Name, Username, Initials and
  Email, into profile.fullname, username, profile.initials and the
  first emails[].address, which is made {address, verified: false} when
  the user has none. It shows WeKan's errors when another user has the
  username or the email (in any case), when the username is empty or has a
  space, and when the email has no @. The name in the header changes on save.
• Change Settings (changeSettingsPopup) has WeKan's toggles: Show desktop
  drag handles, Submit editors with Enter, Open many cards at once and the
  checklist sound. Each is written at once to its profile field, and drag
  handles apply to the board straight away. "Show cards count if list
  contains more than" (profile.showCardsCountAt, -1 and up) and the rescue
  dialogue setting are written on Save.
• New icons, drawn as WeKan's Font Awesome ones: key, flag, sign-out, font,
  picture and paperclip. A text key that only Wena's named texts had now
  also falls back to its English there.
• --show member-menu, --show edit-profile and --show change-settings
  capture them.
• Tests: member-settings checks the menu's order, Admin Panel shown only
  to an admin, the enabled entries, the forms' fields in and out, Save,
  close and the card count's bounds. wekan-sync checks the profile round
  trip, the email array with FerretDB's types, taken and invalid usernames
  and emails changing nothing, and the settings fields, refusing a field
  name that is not plain letters.

Thanks to xet7.

WeKan's mobile/desktop toggle and Show desktop drag handles work on the board

• The mobile/desktop toggle in the header works now. In mobile mode, as
  WeKan's body.mobile-mode, every list takes the board's whole width and
  the lists stack one under another, each as high as its cards (a collapsed
  one is WeKan's 60 pixel bar), and the page scrolls. The icon is WeKan's
  fa-desktop or fa-mobile, and the choice is the user's
  profile.mobileMode, as Users.setMobileMode writes it.
• Show desktop drag handles now draws WeKan's arrows icon on every
  minicard (20 pixels at its right, 28 down; a 44 pixel strip in mobile
  mode), every list header and every swimlane bar, and only those icons drag.
  A click elsewhere on a card still opens it, and a click on a list's or
  swimlane's title still renames it. Before, the toggle swapped the card
  drag for an older labelled handle row.
• --show mobile and --show drag-handles capture either state.
• Tests: nuklear-board renders with the real Nuklear. In mobile mode the
  lists stack at the same left edge and the heights add up. Without
  handles the whole card, header and bar drag; with them only the 20, 22
  and 26 pixel icons (44 in mobile mode), a card body click opens the card,
  and a click on the handle does not. board-feature checks the toggle's
  action in both states, and wekan-sync the profile.mobileMode round
  trip, apart from the drag handles.

Thanks to xet7.