Shell:
- WorkspaceHost: change tooltip from pluginId to human-readable title
- StatusBar: replace pluginId tooltips with label or id (3 occurrences)
- App: startup routing to Today view, sidebar Today nav item
- Sidebar: add Today button in Overview section
- TodaySurface: separate global vs workspace data (no fallthrough)
Plugin API:
- Add workspaces.list() method wrapping App.ListWorkspaces()
(needed by browser-inbox workspace picker)
- onNavigateBack/Forward now skip entirely when currentView === 'workbench'
(user relies on close button, not mouse back)
- onNavigateBack inside workspace checks upBtn.disabled before clicking —
in root folder (no currentPath) button exists but disabled, so navigateBack
falls through to navigationStack for cross-view navigation
- mouseHistoryDirection and keyHistoryDirection also block 'workbench' to
prevent bypass via pointerdown/mousedown listeners
- onNavigateBack/Forward now check for currentView === 'workspace' first
and delegate to Files plugin's up/forward buttons (breadcrumb/Fwd nav)
- Fall back to navigationStack for cross-view navigation
- Removed mouse_monitor.go (xinput test-xi2) — causes phantom X windows,
superseded by GTK-level vendor patch
- Removed startMouseMonitor call from App.Startup
WebKitGTK does not propagate XButton1/XButton2 (buttons 8 and 9) into
DOM events — event.button and event.buttons are always 0 for these
clicks. This prevents the frontend from detecting hardware back/forward
mouse buttons for history navigation.
Solution: patch Wails' window.c on Linux to intercept button-press-event
at the GTK signal level (before WebKit processes it). For button 8/9 we
call webkit_web_view_run_javascript() to dispatch a native CustomEvent
('verstak:navigate-back' / 'verstak:navigate-forward') into the page,
allowing the frontend to navigate history without any workaround on the
JS side.
The patch is applied automatically during build via scripts/build.sh:
go mod vendor → patch -p0 < patches/window.c.button-press.patch
Vendor directory is gitignored.