openclaw / openclaw/openclaw-windows-node

[Feature]: Surface bundled plugin destinations (e.g. Workboard) in Hub navigation

Open
#1,358 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

clawsweeper:needs-maintainer-review clawsweeper:needs-product-decision clawsweeper:no-new-fix-pr impact:ux-friction issue-rating: 🌊 off-meta tidepool P3
Dominant language
C#
Stars
2.1k
Forks
295
Avg merge
1d 6h
Merged PRs (30d)
99

Description

Summary

Let Windows Hub show bundled, featured plugins (such as Workboard) as native navigation destinations instead of only through the web Control UI.

Problem to solve

Workboard ships bundled with OpenClaw, declares featured: true, and adds a Kanban board to the browser Control UI. Windows Hub has no native entry for it.

The current workaround is to switch Hub to surface the web Control UI. That works, but it swaps the whole app into the web view to reach one plugin, instead of letting it sit alongside Chat, Sessions, Cron, and Skills as a peer destination. Users who otherwise live in Hub's native pages have to change how the entire app presents itself to use one bundled feature.

Proposed solution

Have Hub read plugins that declare catalog.featured plus dashboard.dataBindings, and render them as navigation destinations ordered by catalog.order.

The gateway already publishes the full contract. From Workboard's openclaw.plugin.json:

"catalog": { "featured": true, "order": 10 },
"dashboard": {
  "dataBindings": [
    { "id": "cards.list",  "method": "workboard.cards.list" },
    { "id": "stats",       "method": "workboard.cards.stats" },
    { "id": "boards.list", "method": "workboard.boards.list" }
  ],
  "actionVerbs": [
    { "id": "dispatch", "method": "workboard.cards.dispatch" }
  ]
}

This is a client gap, not a missing contract. A generic host would cover every current and future plugin rather than one-off work per plugin.

Alternatives considered
  1. A dedicated Workboard page: add Tag="workboard" to HubWindow.xaml, route it in HubWindow.xaml.cs, add Pages/WorkboardPage.xaml modeled on CronPage (also a gateway-data list view), plus a sidebar icon and Resources.resw entries. Smaller and faster, but hardcodes one plugin and does not generalize to the next one.

  2. Keep using the web Control UI view. Works today, but means switching the whole app presentation to reach a single bundled plugin.

Impact

Affected: Windows Hub users running bundled plugins, particularly Workboard, which is featured and enabled-by-default-eligible.
Severity: Annoying, not blocking. A workaround exists.
Frequency: Every time the plugin is used. For Workboard as a task board, that is several times a day.
Consequence: Context switching out of Hub's native navigation, and inconsistency between what the Control UI offers and what Hub offers for the same gateway. Grows with each new featured plugin.

Evidence/examples
  • Workboard plugin docs: https://docs.openclaw.ai/plugins/workboard ("adds an optional Kanban-style board to the Control UI")
  • Workboard manifest declares catalog.featured, catalog.order, dashboard.dataBindings, and dashboard.actionVerbs, so the surface is already described in a client-agnostic way.
  • Hub's navigation is defined in src/OpenClaw.Tray.WinUI/Windows/HubWindow.xaml, where Chat sits above a separator and a "Gateway" group holds Connection, Sessions, Skills, Channels, Instances, and Cron. Every item follows the same NavigationViewItem + Tag + ImageIcon pattern, so a generic host or an added destination both fit the existing structure.
  • Environment: Windows Hub connected to a remote Gateway (OpenClaw 2026.8.2, Docker on Synology). Workboard enabled and working via CLI and Control UI.
Do you plan to open a PR for this?

Maybe, with maintainer guidance

Additional information

Happy to help with the implementation, but would like a steer on direction first: whether Hub should mirror Control UI plugin destinations generally, or stay a curated native set with plugins added deliberately. That choice decides between the generic host and the one-off page, and it seems worth a maintainer's call before code.

Either approach should be additive to existing navigation and should not change behavior for users who prefer the web Control UI view.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with src/OpenClaw.Tray.WinUI/Windows/HubWindow.xaml and HubWindow.xaml.cs to understand the existing navigation structure, then compare the proposed generic host with Pages/WorkboardPage.xaml modeled on CronPage. Confirm how the gateway exposes catalog.featured, catalog.order, and dashboard.dataBindings. Done means a maintainer-approved approach surfaces eligible bundled plugins without changing existing web Control UI behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
39/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.