5830198566
Some checks failed
Security / Security check (push) Failing after 1s
Previous "left-anchor everything via padding" approach made
the math work on paper but the perceived shift persisted. The
root cause was structural, not padding-based: ListView gave
each item a tight cross-axis constraint equal to the rail's
current width (48 collapsed, 196 expanded). Inside the item,
the AnimatedContainer filled that constraint and laid out a
mainAxisSize.min Row at the start of the AC's content area.
The icon's pixel-X depended on the AC's padding _and_ the
constraint; even with equal padding the rendered layout
shifted across the expand animation because Flutter
re-resolved alignment under a moving constraint.
Replace the entire pattern with a fixed-width icon column
that doesn't care about the parent constraint:
ListView (padding 0) → Item Row
SizedBox(width: 72) → Center → icon ← anchored to literal x
if expanded → Expanded → label text ← grows into remaining space
Same pattern for the brand/connection/channel rows above. The
72 px matches the rail's collapsed width exactly, so collapsed
rail = one icon column + nothing; expanded rail = same icon
column + label slot. Icon's pixel-X is now provably constant.
Removes the AC's horizontal padding entirely — the icon
column owns the left anchor. The background highlight still
spans the full row width (typical nav-rail UX), and the rail
expand animation only moves the rail's right edge, never any
icon-bearing element.
Also passes an `iconColumnWidth: 72` to _SidebarItem instead
of hard-coding the magic number in two places.
Version 0.51.3 → 0.51.4.
Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
|
||
|---|---|---|
| .forgejo/workflows | ||
| .githooks | ||
| assets/docs | ||
| docs | ||
| lib | ||
| linux | ||
| macos | ||
| test | ||
| tools | ||
| windows | ||
| .gitignore | ||
| .metadata | ||
| .security-allow | ||
| analysis_options.yaml | ||
| l10n.yaml | ||
| pubspec.lock | ||
| pubspec.yaml | ||
| README.md | ||
F∆I Studio
Desktop GUI client for the F∆I Platform hub. Tier-2 generic
platform client per docs/architecture/client.md. Connects to a
local or remote fai serve over gRPC.
Status (2026-05-05): MVP scaffold. Three pages with mock data, no live gRPC connection yet. Validates the visual direction before the Dart SDK is wired in.
Pages (MVP scope)
- Modules — installed modules, capabilities, declared permissions. Click → manifest detail.
- Audit — live stream of hub events (when wired). Filter by event type and flow.
- Approvals — pending
system.approval@^0reviews with approve / reject buttons.
These three cover the platform's central properties: composition (modules), audit (events), human-in-the-loop (approvals).
Stack
- Flutter 3.40+ (Desktop: macOS, Linux, Windows)
- gRPC client via
fai_client_sdk(sibling repo; pinned by relative path during development) - No external runtime dependencies; bundles its own Dart VM
Run locally
flutter run -d macos
Repo placement
Will be published as fai/studio on Forgejo (git.flemming.ws).
The local directory fai_studio/ follows the established
fai_platform/ layout convention.
Why "Studio" and not "Stage"
"Stage" collided too easily with "staging environment" in
developer English. "Studio" is the established industry pattern
for creator-tools (Visual Studio, Android Studio, RStudio) and
matches the GUI's audience of module developers, operators, and
power users. The rename was applied across all docs/ in the
platform repo on 2026-05-05.