Publish topic guides to the wiki and document tabbed windows

Publish the guides from this repository to the GitHub Wiki. Organize them into Usage, Configuration and Development, with 15 separate configuration topics and redirects for the former website guide URLs.

Add a tabbed-windows guide covering grouping, switching tabs and taking windows out. Document the scrolling indicator's defaults and limits, and link the guide from the README, shortcuts and IPC pages. Update from main, including the latest tabbed-layout changes.

Separate Activities setup, configuration and publishing documentation. Review the guide prose with the unslop skill, keeping existing examples and heading links. The wiki workflow uses GitHub's built-in token to publish documentation changes on main.

Validation:

- 20 documentation tests pass, including README links and Activities/tab-indicator field coverage.
- The publisher builds 46 wiki pages; the site build and Python syntax checks pass.
- All 115 code examples from main are preserved.
- The Python suite passes: 90 tests passed and 31 opt-in integration tests skipped, with the system GI module available.
This commit is contained in:
Samuel Onoja authored and GitHub committed 2026-10-13 00:32:23 +01:00
1 parent eaeabebe73
commit eb84104940
37 files changed
+2178 -1510

No files matched your search

+8 -8
View File
@@ -15,9 +15,9 @@ Use release builds for performance and animation checks. Preview changes in a
[nested session](installation.md#preview-and-logs) before testing hardware behavior.
Keep another desktop available for direct-session recovery.
Run CI manually when a change needs it. Ordinary pushes and pull requests do not
start build runners, and website deployment is manual. Release tags and pull
requests labeled `release` run the release checks and package builds.
Workspace checks and website deployment run manually. Documentation changes on
main publish to the wiki automatically. Release tags and pull requests labeled
`release` run the release checks and package builds.
The workspace workflow checks formatting, lints and tests on Ubuntu, including
the shell, Settings, portal and CLI. It builds the desktop binaries, runs the
@@ -29,15 +29,15 @@ host. Hardware checks remain separate.
- [Live Activities checks](#live-activities-checks): core, CLI, shell hooks, installer setup and native rendering.
- [Desktop reconciliation](desktop-reconciliation.md): topology publication, hardware failure and presentation ownership.
- [Output management tests](output-management-testing.md): profiles, hotplug, mirroring, lid handling and failed DRM commits.
- [Nested resize checks](nested-resize-testing.md): wallpaper and bar responsiveness.
- [Client soak testing](native-soak-testing.md): repeated client lifecycle and resource growth.
## Live Activities checks
See [Live Activities](activities.md) for setup, configuration and the publisher
protocol.
See [Live Activities](activities.md) for setup and use,
[Activities configuration](configuration/activities.md) for settings, and
[Publishing activities](development/activities.md) for the IPC protocol.
Hidden items and measurement widgets do not animate. Reduced motion snaps
progress and uses a static track. Workspace buttons retain their own actions;
@@ -133,7 +133,7 @@ cargo test --release --locked -p ferese session_lock::tests -- --nocapture
```
These tests create private runtime directories and Wayland clients. They run in
normal test suites and in the compositor lifecycle CI job, without a host desktop or DRM.
normal test suites and in the workspace CI job, without a host desktop or DRM.
They cover confirmation, rejected unlocks, owner death and replacement, output
removal, keyboard focus and idle timers. Physical display protection still needs
hardware testing.
@@ -146,7 +146,7 @@ cargo test --release --locked -p ferese resume::tests -- --nocapture
These tests need `dbus-daemon`. They use a private bus to test missed resumes,
logind replacement and listener shutdown during connection setup, signal waits
and retries. They run in the compositor lifecycle CI job and never contact system logind.
and retries. They run in the workspace CI job and never contact system logind.
Recovery requests fresh hardware and theme state without resetting idle activity.
Hardware suspend/resume still needs testing on a direct session.