docs: clarify Fyne/UI roadmap blockers and missing upstream APIs

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
mixeme
2026-08-07 22:32:30 +03:00
parent 565728032c
commit 51350d476c
+31 -9
View File
@@ -116,10 +116,20 @@ needs the same treatment.
## Fyne / UI ## Fyne / UI
Work blocked on Fyne APIs, driver behaviour, or missing composable widgets. GUI-layer gaps and trade-offs. Each item below states its **blocker**:
- **Fyne API** — the missing API is the root cause. Qt, GTK, and native
toolkits usually expose the same capability; a future Fyne release is the
preferred fix. Some items have no viable workaround; others could be bypassed
with `src/platform/` code, but that cost is not justified while upstream might
still add the API.
- **UX** — shippable with today's widgets; deferred until a cleaner approach
exists (a nicer Fyne widget would help but is not required).
### Dynamic tray icon toggle ### Dynamic tray icon toggle
**Blocker: Fyne API** (no viable workaround).
Fyne exposes `SetSystemTrayIcon` and related APIs only at application startup. Fyne exposes `SetSystemTrayIcon` and related APIs only at application startup.
There is no supported way to register or remove the notification-area icon There is no supported way to register or remove the notification-area icon
after the process is running. after the process is running.
@@ -136,22 +146,34 @@ is blocked.
### History tab — column filters (Trigger / Job / State) ### History tab — column filters (Trigger / Job / State)
**Blocker: UX** (not a Fyne release).
Add dropdown filters above the History table so the user can narrow rows by Add dropdown filters above the History table so the user can narrow rows by
trigger source, job name, or run state. Blocked on Fyne native support: the trigger source, job name, or run state. A filter bar built from `widget.Select`
current `widget.Table` has no built-in filter API, and a filter bar built from widgets above the table would work today — filter the row slice in app code —
`widget.Select` widgets above the table feels visually out-of-place. Revisit but `widget.Table` has no built-in filter API and the ad-hoc bar feels visually
when Fyne adds first-class column filtering or a composable data-grid widget. out-of-place. Revisit when Fyne adds first-class column filtering or a
composable data-grid widget, or when a hand-rolled bar is acceptable.
### Window size persistence *(frozen)* ### Window size persistence *(frozen)*
**Blocker: Fyne API** (costly platform workaround possible).
Window size is currently **not** saved on quit or close. Saving was disabled Window size is currently **not** saved on quit or close. Saving was disabled
because `w.Canvas().Size()` returns the maximized dimensions when the window is because `w.Canvas().Size()` returns the maximized dimensions when the window is
maximized, which would corrupt the stored size on the next launch. maximized, which would corrupt the stored size on the next launch.
Re-enabling requires a cross-platform way to detect the maximized state before Fyne v2.x has no API to query window state (maximized, normal, etc.) — unlike
saving. Fyne v2.x has no API for this; it needs per-OS native calls: Qt, GTK, or platform-native toolkits. If Fyne added something like
`IsZoomed` (Windows), `_NET_WM_STATE` (X11/Linux), `NSWindow.isZoomed` `Window.IsMaximized()`, persistence could be re-enabled without any
(macOS). Unfreeze once that detection is in place. platform-specific code; that upstream API is the preferred unblock.
A bypass through per-OS native detection (`IsZoomed` on Windows,
`_NET_WM_STATE` on X11, `NSWindow.isZoomed` on macOS) is technically possible,
similar to other `src/platform/` work, but Fyne does not expose the underlying
window handle, so the bypass is fragile and expensive. The item stays frozen
until either Fyne ships window-state API or that platform cost is judged worth
paying.
**Disadvantages of a platform-specific approach:** **Disadvantages of a platform-specific approach:**