This uses Gambas for WebUI app with SQLite database.
The current implementation has native Gambas controls for boards, cards, search, archives, profile/password settings and administrator user management. Lists, swimlanes, tables, a month calendar, due-date milestones and status charts are rendered with local HTML/JavaScript/CSS inside a Gambas WebContainer. These reports read the same persisted cards. There are no external browser-library or CDN dependencies.
This is not yet full parity with the current Meteor WeKan application. See TODO.md for active work, verification and the remaining pages/components. The Gantt page currently shows due-date milestones, not task durations/dependencies; charts show current counts, not historical forecasts.
Developed by WeKan ®.
Gambas has IDE similar to VB6. Gambas can create GUI, WebUI and CLI apps.
Note: Gambas seems to have very advanced RAD GUI Menu editor. It is possible to multi-select many menu items at once and move them right to be submenu, or move to left.
- At Win11 WSL2 now supports installing GUI apps:
https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps
- Install Gambas daily PPA by adding it from:
https://launchpad.net/~gambas-team/+archive/ubuntu/gambas-daily
- Install Gambas with:
sudo apt install gambas3
- Start with:
gambas3
-
And it opens Gambas GUI.
-
Related: SystemD on WSL2
https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/
- Run
./install-deps.sh - In Gambas, click Open Project, and select directory WeKan.
- Click play button that looks like triangle to right. This starts webserver and opens webbrowser.
- Click Register, enter a username and a nonempty password, repeat the password, then click Create account. Show password / Hide password toggles visibility on both login and registration forms. The first successfully registered account is Admin; subsequent registrations are Normal. Registration also signs the user in. For later visits use Login. No default accounts or passwords are shipped.
- The app creates
WeKan/database.dband its schema on first use. Keep a backup of this runtime file; it is ignored by git. An existing installation retains its accounts: removing the bundled demo database does not migrate deployed data. Short passwords are accepted by default. Admin panel → Password Length lets an administrator enable a minimum of 1–256 characters. The configured minimum applies to registration and newly chosen passwords (creation/change/ reset) only while enforcement is enabled; existing credentials remain valid. - Create a board, select it in the tree and click New card. Edit a card by
selecting it in the tree. Lists start with
Todo,DoingandDone; custom lists are supported. Dates useYYYY-MM-DD. The reports support all owned boards or the selected board.
SQLite is the default and the tested backend. Schema creation uses Gambas field
and primary-key APIs. Data access uses Find, Create, Edit, LastInsertId
and parameterized Exec, without SQLite-specific SQL syntax or date functions.
Other writable Gambas database drivers still need conformance testing; enable
that driver's component in the project before selecting it.
Connection environment overrides: WEBA_DB_TYPE, WEBA_DB_HOST, WEBA_DB_NAME,
WEBA_DB_USER, WEBA_DB_PASSWORD. Server databases must already exist and grant
schema-creation permissions. Usernames are primary keys. A transactional unique
bootstrap claim prevents concurrent registrations from creating two first admins;
a losing concurrent request may need to retry. Database credentials are not logged.
In the parent WeKan checkout the user-provided Gambas files are in
.tools/bin/gambas3: bin/ contains IDE archives, lib/gambas3/ components,
usr/share/gambas3/info/ class metadata and src/gambas/ upstream source. The
initial copy did not contain gbc3 or gbx3 in bin/; verify the files and CPU
architecture before using it. IDE archives require a Gambas interpreter.
With a complete Gambas installation, from this repository:
export TMPDIR="$(pwd)/.tools/tmp"
mkdir -p "$TMPDIR"
gbc3 -j 1 -a WeKan
./tests/run-store.sh
python3 tests/run-http.py
NODE_PATH="$(pwd)/../../node_modules" node tests/reports.test.cjsGBC and GBX override the compiler and runner executables for the test runners.
A relocated compiler can use gbc3 -r <prefix> through a local wrapper. A relocated
runner may require GB_PATH and LD_LIBRARY_PATH. The initial ARM64 checks used
locally extracted Debian Gambas 3.20.2 packages under the parent checkout's
.tools/tmp/weba/gambas; no system packages were installed.
Store/authentication tests create fresh temporary databases, covering registration
roles, CRUD, archives, validation, password changes and forbidden operations. The
HTTP runner copies the sources into a temporary project and runs the real Gambas
CGI/session protocol on localhost, preserving local runtime paths that the embedded
HTTP server can discard. It covers registration/login, board/card creation, report
resources, view switching, profile/admin pages and logout. DOM tests require jsdom
and cover report rendering, date navigation and untrusted text. These checks do not
replace a real browser visual/accessibility test or cross-driver conformance run.
Run ./build.sh for the menu, or use build, run, test, package,
release-all, release-all-missing, copy-gambas, targets and doctor.
run builds a single .gambas archive and serves it on localhost:8080 with
runtime/server.py. If 8080 is occupied, the OS assigns a free port; use the
URL printed at startup. ./build.sh run --port 0 always chooses a free port.
An explicit nonzero --port remains fixed (useful for container port mappings).
Runtime data defaults to $XDG_DATA_HOME/weba (or
~/.local/share/weba) outside the installed program directory. Python 3 and
the Gambas runtime/components are required. Development tests also need Node.js
and jsdom (nodejs and node-jsdom on Debian).
Copy Gambas to Flatpak Sandbox reads the host's /usr/bin, /usr/lib/gambas3,
/usr/share/gambas3, /usr/local equivalents, Gambas desktop metadata, icons
and man pages. It also includes gbc3, gbx3, gba3 and gbr3, which are not
found by searching only for filenames containing gambas. Inside Flatpak the
helper runs with flatpak-spawn --host; launch this action on the host if that
service is unavailable. It writes the parent checkout's .tools/bin/gambas
(or this clone's .tools/bin/gambas when standalone), preserving a conventional
usr/ tree and creating bin/ wrappers with relocated compiler/component paths.
The older manually copied gambas3 directory remains a fallback. Native library
dependencies are copied locally without replacing the sandbox libc/loader.
Copying does not guarantee host/Flatpak libc compatibility; run ./build.sh doctor
A35F
.
GAMBAS_COPY_DEST changes the destination and GAMBAS_SOURCE_ROOT supports
fixture/alternate installation roots. No sudo installation is performed.
Release targets are defined once in releases/targets.json:
| Target | Release files |
|---|---|
| Linux amd64, arm64, armhf, armel, i386, ppc64el, riscv64, s390x | .deb and .tar.gz, built/tested on that CPU through Debian/QEMU |
| Windows amd64, arm64 | WSL installer .zip, requires Debian 13+ in WSL |
| macOS amd64, arm64 | Docker Desktop launcher .zip with the matching Linux package |
| Source | .tar.gz for building on other systems with a compatible Gambas runtime |
These are runtime-dependent packages. WSL/Docker launchers are not native Windows/macOS Gambas binaries. Native BSD/macOS and additional architectures need a verified Gambas Web UI/runtime build before being added to the matrix. The eight Linux platforms match the Debian trixie image architectures; see the official Debian image definitions. CPU/OS jobs that fail tests fail visibly and do not publish unfinished artifacts. The Windows and macOS launchers have not yet been exercised on those systems.
Human release procedure:
- Commit the desired version on
main, review the changes and tests, and push it yourself. Create and push an existingvMAJOR.MINOR.PATCHtag containing these workflows; the scripts never create or push refs. - Run
./build.sh release-all v1.1.0(example tag) or select Release All. It dispatchesrelease-all.ymlinwekan/webathrough the GitHub CLI. The workflow checks out the tag, tests/packages each target independently and attaches each completed package with its SHA-256 file as soon as it finishes. The AI git boundary means a human must execute this publishing action. - Run
./build.sh release-all-missing v1.1.0to complete an interrupted release. A target is complete only when all its package/checksum pairs exist. Existing complete pairs are preserved; an orphaned checksum is calculated from the already published package bytes. Source and other CPU jobs proceed independently.
The local CLI requires a clean checkout, an existing remote tag and a working
gh login with workflow-dispatch permission. The manually invoked workflows use
GITHUB_TOKEN with contents: write to create releases and attach assets. They
share a per-version concurrency group and never cancel an in-progress release.
No workflow has been dispatched as part of preparing this implementation.
The signed-in shell follows the current WeKan control order using Gambas controls: Home, navigation collapse, page title/logo, available page actions, view menu, account menu and page-sidebar toggle. Board/archive navigation is on the left, board tiles or the selected report occupy the center, and page actions open in an optional right sidebar. Card fields appear in a closable panel only when creating/selecting a card. Profile and password-policy forms occupy the content area; the administrator's available sections use the left navigation.
Only implemented functions are offered; matching the component placement does not imply all WeKan features have been ported. The current layout was compared against the running WeKan UI and checked in Chromium at 1440×1000 and 390×844. The browser test checks geometry, native menus, board/card creation, calendar, admin navigation, panel toggles and the native keyboard-focus outline.
For an isolated real-browser test, provide a Chromium CDP endpoint and Puppeteer available to Node (for example the enclosing development checkout's dependencies):
WEBA_BROWSER_URL=http://127.0.0.1:9231 python3 tests/run-http.py --browser --archiveThe runner copies sources into a temporary project, creates a fresh test database
and closes its test server afterward. WEBA_SCREENSHOT_DIR optionally saves
screenshots to an existing task-owned temporary directory. It does not use your
normal browser profile or application database. Chromium must be started with
its own disposable profile and remote-debugging port before running this check.
Board tiles and swimlane/list/card headers open native Gambas context menus. Rename/copy, colors, stars, WIP limits, same-board moves, archives/restoration, scoped history and JSON export persist through owner-checked database operations. Card/list/swimlane menus also move items between owned active boards. Relationships must stay within one board: a move that splits a subtask/dependency group is rejected. Archived items can be permanently removed by typing their exact title; container removal includes its cards, file bytes and dependent records.
The card editor and menu provide comments, checklists/items, real subtask cards, dependencies, card-level text/number/date/checkbox fields, time entries/timers and native attachment upload/download (10 MiB each). Copying containers/cards preserves rich records and remaps internal links. Running timers are excluded from copies. Watch preferences are saved, but notification delivery is still pending.
The page sidebar's Import weba JSON file control imports a weba-2 export into
a new board after confirming its title. JSON exchange includes empty layouts,
order, archive state, metadata, rich records and base64 file content; identifiers
are remapped transactionally. Import JSON is limited to 20 MiB. Imported running
time entries become stopped records. This format does not yet accept Meteor
WeKan export files or transfer activity history/member accounts.
Focused isolated browser checks use the same runner as the layout test:
WEBA_MENUS_ONLY=1 WEBA_BROWSER_URL=http://127.0.0.1:9231 python3 tests/run-http.py --browser
WEBA_DETAILS_ONLY=1 WEBA_BROWSER_URL=http://127.0.0.1:9231 python3 tests/run-http.py --browser
WEBA_TRANSFER_ONLY=1 WEBA_BROWSER_URL=http://127.0.0.1:9231 python3 tests/run-http.py --browser --archive
WEBA_EXCHANGE_ONLY=1 WEBA_BROWSER_URL=http://127.0.0.1:9231 python3 tests/run-http.py --browser --archiveShared membership/roles, public boards, rich text, board-level field definitions,
notification delivery, full administrator menus, automation and integrations
remain tracked in TODO.md. SQLite on Linux ARM64 and Chromium are tested;
other Gambas database drivers and browsers still require conformance checks.
Color dialogs offer WeKan's preset colors as native Gambas buttons, a browser
color-wheel picker and a synchronized #RRGGBB field. Lists/swimlanes use the
25-color item palette; cards omit white as WeKan does. Boards offer 25 theme
color samples. Gradient/special board themes currently apply a solid base/first
color stop; their complete theme styling remains future work. Refresh the
source snapshot with python3 tools/import-wekan-colors.py /path/to/wekan.
The isolated color workflow is checked with WEBA_COLORS_ONLY=1 and the browser
runner above, covering persisted values, invalid hex input and mobile placement.
The login page and signed-in account menu have a language selector. The selected
language is saved in this browser; a new browser starts with its preferred language
when available. The imported WeKan catalog currently provides 92 matching interface
keys for 237 languages, including their native language names and RTL metadata.
Only the selected catalog is fetched, from local application assets. No external
translation service is used. Labels and report/calendar headings are translated;
user data and stored workflow statuses are preserved. Weba-specific messages with
no matching WeKan key remain English (WeKan/.public/i18n/manifest.json).
Refresh the imported subset from an actual WeKan source checkout:
python3 tools/import-wekan-translations.py /path/to/wekanThe importer copies existing translation values verbatim without changing WeKan files. It writes the language metadata, selected catalogs and a source fingerprint. Review alias mappings when adding interface text. Translation data originates in WeKan, copyright Lauri Ojansivu, under the MIT license included with this repository.
node tests/i18n.test.cjs checks catalogs, persistent selection, RTL, AJAX updates,
English fallback and protection of user content. The isolated browser translation
check can also run with WEBA_I18N_ONLY=1 WEBA_BROWSER_URL=http://127.0.0.1:9231
and python3 tests/run-http.py --browser --archive against a local Chromium CDP
instance, using the same Gambas environment as the other HTTP tests.
Opening a board selects Swimlanes. Each swimlane has collapse/menu/add-swimlane controls at the right of its header. Each list has collapse at its top-left and add-card/menu/add-list at its top-right, plus an Add card action below its cards, following the current WeKan component templates. The list composer opens directly after the chosen list. Empty swimlanes and custom lists are saved in the database; legacy card swimlanes are retained when the layout tables are initialized.
Card buttons open the native Gambas editor with the correct swimlane/list, and
card tiles open their existing details. Custom list names are limited to 32
characters to fit the existing portable card schema. This does not yet implement
all WeKan list/swimlane menu actions or creating a new card at the top through
the header button. Existing cards can be reordered by dragging. WEBA_SWIMLANES_ONLY=1 selects the dedicated Chromium layout/action test
with tests/run-http.py --browser (also supports --archive).
Interface icons use the same locally bundled Font Awesome 6 assets and legacy
aliases as WeKan (including regular/brand icons and its fa-times-thin close
alias). No icon CDN is required. Card details open near their initiating action;
position and maximum size track the visible viewport, including mobile landscape
and viewport changes when the on-screen keyboard opens. Long content scrolls
inside the window. Popups have a top-right X and Escape dismissal; closing card
details returns focus to the initiating control when that control still exists.
node tests/popup.test.cjs checks placement at viewport edges and reduced visual
viewports. WEBA_POPUPS_ONLY=1 selects browser checks for anchored card editing,
reachable close buttons, view/account/structure menus and portrait/landscape
behavior in the isolated tests/run-http.py --browser harness.
Use the Font Awesome arrow handle on a card, list or swimlane to drag it, as in WeKan's touch mode. Touch targets expand to at least 44 pixels; card handles sit on the trailing edge below the title area. Movement starts after 7 pixels. Touching elsewhere keeps normal browser scrolling and tapping a card still opens its details. On a mouse, a card can also be dragged from its surface. Focus a handle and use arrow keys for keyboard moves. Drag near a scrollable edge to auto-scroll; Escape, touch cancellation or a second finger cancels without saving.
Cards can be reordered and moved between lists/swimlanes within the current
board. Lists can be reordered or moved to another swimlane with their cards;
touch/small-screen moves ask for confirmation. Swimlanes can be reordered. Moves
are owner-checked, rejected for archived boards/cards, saved transactionally and
retained when reopening the board. Existing data receives a separate kb_order
metadata table; card descriptions, labels, dates and ownership are preserved.
Cards retain a stable list ID, so moving a list into a swimlane that already has
a list with the same title keeps the two lists and their cards separate. Existing
name-based assignments are retained when identity metadata is initialized.
Cross-board drag moves remain future work.
node tests/drag.test.cjs checks gesture selection, threshold, cancellation,
UTF-8 transport and keyboard input. tests/DragStoreTest.module runs in the
isolated store harness. WEBA_DRAG_ONLY=1 selects the Chromium CDP touch/mouse
checks in tests/run-http.py --browser (also --archive). Actual physical touch
hardware and non-Chromium browsers have not been tested.