GTK: route gtk4::FileDialog calls through PlatformServices (Stage G of #493)

[JDonaghy]

Summary

Route vimcode's remaining direct gtk4::FileDialog usage through
quadraui's PlatformServices trait instead of constructing GTK dialogs
in-line. This is Stage G from the wave plan in #493 — split out as its
own narrowly-scoped issue after #493 was closed as superseded (its core
ask, collapsing 14 DrawingAreas to 1 and stripping Relm4, already shipped
via #447/#448).

Current state

Three call sites in src/gtk/mod.rs build gtk4::FileDialog directly and
drive its async callback API:

• src/gtk/mod.rs:7319-7337 — Msg::OpenFileDialog
• src/gtk/mod.rs:7338-7355 — Msg::OpenFolderDialog
• src/gtk/mod.rs:7362-7376 — Msg::SaveWorkspaceAsDialog

This is exactly the kind of per-backend platform code the
Platform-Neutrality Rule flags — it's GTK-only, has no TUI equivalent, and
belongs behind the shared PlatformServices seam instead.

Blocked on

quadraui#427 — GtkPlatformServices::show_file_open_dialog /
show_file_save_dialog are currently hard stubs returning None
(quadraui/src/gtk/services.rs:40-46). GTK4's FileDialog API is
async-only, which is why this was never filled in — see quadraui#427 for
the full analysis and proposed nested-mainloop adapter. This vimcode issue
can't land until that ships.

Acceptance

• All three call sites above go through PlatformServices::show_file_open_dialog() /
  show_file_save_dialog() (via whatever engine/backend accessor
  ShellApp/Backend already expose for services) instead of constructing
  gtk4::FileDialog directly.
• Zero direct gtk4::FileDialog (or other native file-chooser) references
  remain anywhere in src/gtk/.
• TUI backend unaffected (it already returns None from the stub path per
  the trait doc comment, and provides its own in-TUI picker).

Related

• Full GTK run_with_shell migration: collapse 14 DAs to 1, strip Relm4 #493 (closed, superseded) — original wave plan, this is its Stage G.
• Migrate GTK widget tree to quadraui AppShell + run_with_shell() #447, Migrate GTK event dispatch to ShellApp::handle(UiEvent) #448 — landed the rest of the run_with_shell migration this
  issue's prerequisite section referenced.
• quadraui#427 — blocking prerequisite (real GTK file-dialog impl).

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: —

Summary

Migrated OpenFileDialog + SaveWorkspaceAsDialog to quadraui::PlatformServices (backend.services().show_file_open_dialog/show_file_save_dialog), deferred via a PendingFileDialog Cell drained in tick() since dispatch() has no backend param. OpenFolderDialog stays on direct gtk4::FileDialog::select_folder — quadraui::PlatformServices has no folder-select mode, discovered mid-implementation and not in the original issue's scope. Needs a NEW quadraui issue (coordinator should file: 'Add folder-select dialog mode to PlatformServices/FileDialogOptions') before the third call site can migrate; #572 should stay open for that. Build/clippy/fmt clean, full test suite + gui-feature lib tests (2015 tests) pass. Pushed to issue-572-gtk-route-gtk4-filedialog-calls-through, no PR opened per workflow.

[JDonaghy]

Coordinator: Assignment Complete

Machine: elitebook
Status: done
Exit code: 0
Duration: —

Summary

Smoke passed: Open File/Save Workspace As dialogs work via PlatformServices, Open Folder still native (expected), no re-entrancy crash. Found unrelated pre-existing 'Save As' no-op bug on develop (out of scope for #572).

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: —

Summary

Approve: #572 correctly migrates OpenFileDialog/SaveWorkspaceAsDialog through PlatformServices via tick()-deferred pattern; OpenFolderDialog rightly left blocked on missing quadraui folder-select support

Verdict: approve

Review findings

Review: #572 — route gtk4::FileDialog calls through PlatformServices

Reviewed origin/issue-572-gtk-route-gtk4-filedialog-calls-through vs origin/develop
(single commit 7fdb196, src/gtk/mod.rs only, +88/-28). Per the review harness
instructions I did not run cargo build/cargo test/clippy — that's the separate
pre-merge smoke gate's job — but I did a careful static read of the diff plus the
actual quadraui trait definitions/impls it calls into (~/src/quadraui), since a
wrong assumption about trait-object method resolution would be a real compile risk
here.

What the diff does

• Msg::OpenFileDialog / Msg::SaveWorkspaceAsDialog (in handle_dialog_msg) no
  longer build gtk4::FileDialog + async callback in-line. They now stash a new
  PendingFileDialog enum in a Cell<Option<PendingFileDialog>> on App, which
  tick() drains and hands to a new run_pending_file_dialog() that calls
  backend.services().show_file_open_dialog() / show_file_save_dialog() on the
  runner-owned backend: &mut dyn quadraui::Backend tick() already receives.
• Msg::OpenFolderDialog is deliberately left untouched (still direct
  gtk4::FileDialog::select_folder), with a comment explaining why:
  quadraui::PlatformServices has no folder-select mode yet.
• No changes to src/tui_main/ or src/core/ (verified: diff against those paths
  is empty).

Correctness

• The PendingFileDialog deferral correctly respects the pinned constraint that
  self.backend (App's own GtkBackend field, used only for
  modal-stack/drag-state) must never be used for PlatformServices calls, because
  only the runner-owned backend param has its pump_depth wired to the runner's
  event controllers for the refactor: GTK action menu engine-drawn; drop dead right-click bodies (#395) #427 re-entrancy guard. The doc comments on
  PendingFileDialog and run_pending_file_dialog correctly explain this and match
  what's actually in the file (verified dispatch_engine_action at :2339 and
  handle_menu_msg at :5273/:5283 are indeed the callers feeding into dispatch()
  → handle_dialog_msg() the comment describes).
• Trait-object method resolution: run_pending_file_dialog calls
  backend.services() and then .show_file_open_dialog(...) without a local
  use quadraui::Backend;/use quadraui::PlatformServices;. I double-checked this
  isn't a miss — Backend/PlatformServices methods are being called through dyn Backend/dyn PlatformServices receivers, which don't need the trait imported
  (only concrete-type receivers do — confirmed by the pre-existing local use quadraui::Backend; blocks in this same file at other call sites, all of which are
  on the concrete self.backend: RefCell<GtkBackend>, never on the dyn Backend
  param). tick() itself already calls backend.line_height()/char_width() on
  the same dyn Backend param with no import, which is existing, presumably-working
  code — consistent with this reading.
• FileDialogOptions derives Default (quadraui/src/backend.rs:970), so
  ..Default::default() is valid; initial_filename is correctly plumbed by
  GtkPlatformServices::show_file_save_dialog into dialog.set_initial_name()
  (quadraui/src/gtk/services.rs:108-117), matching the old
  dialog.set_initial_name(Some(".vimcode-workspace")) behavior.
• Confirmed quadraui#427 (blocking prerequisite named in the issue) has actually
  shipped in the local ~/src/quadraui checkout — show_file_open_dialog/
  show_file_save_dialog are real nested-mainloop-pumped implementations, not the
  None-returning stubs the issue was blocked on.
• Replacing the async sender2.send(Msg::RefreshFileTree) with a direct
  self.dispatch(Msg::RefreshFileTree) is fine — the call is now synchronous (the
  dialog call itself already blocks), and direct re-dispatch is an existing pattern
  in this file (e.g. Msg::OpenWorkspaceDialog).
• No engine RefCell is held open across the blocking dialog call — borrow_mut()
  only happens after show_file_open_dialog/show_file_save_dialog returns — so
  there's no risk of the nested-mainloop pump re-entering into a live engine
  borrow.

Scope / Platform-Neutrality Rule

Stays within scope. It doesn't add new per-backend business logic — it routes two
call sites through the existing shared PlatformServices seam, and the
PendingFileDialog/tick()-drain mechanism is justified plumbing (not
business logic) to work around dispatch() not having a backend handle, which is
well-documented inline. OpenFolderDialog is correctly not migrated, since
quadraui::FileDialogOptions (quadraui/src/backend.rs:971-980) genuinely has no
directories_only/folder-select field yet — confirmed by reading the struct
directly, matching the pinned context.

One non-blocking follow-up

The issue's acceptance criteria say "zero direct gtk4::FileDialog references
remain anywhere in src/gtk/" — that's not fully met (OpenFolderDialog still has
one at what is currently the handle_dialog_msg match arm). That's the right call
given the tooling gap, not a defect in this PR. But the pinned operator context says
a quadraui issue for folder-select support should be filed, and I see no evidence
one has been (commit message just says "That gap needs a new quadraui issue" without
a number/link). Recommend: file that quadraui issue now, and don't close #572 as
fully resolved on merge — either keep it open for the OpenFolderDialog remainder or
spin a narrow follow-up issue, so the gap doesn't get lost.

Tests

None added. Consistent with the rest of this file — the pre-existing
OpenFileDialog/SaveWorkspaceAsDialog/OpenFolderDialog handlers were untested
GTK glue before this change too (native OS dialogs aren't practically unit-testable
here), so I'm not treating this as a gap worth blocking on.

Security

No new attack surface — paths still come from the OS-native picker and flow straight
into the same engine.open_file_with_mode/save_workspace_as/open_folder calls as
before, just sourced from Option<PathBuf> returned synchronously instead of parsed
out of an async GTK callback's gio::File.

Verdict

Approve. The migrated call sites are correct and well-justified against the pinned
architectural constraints; the deferred OpenFolderDialog site is a legitimate,
documented tooling gap rather than a shortcut. Only ask is the non-blocking
follow-up above (file the quadraui folder-select issue, don't fully close #572).

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: —

Summary

Rebased issue-572-gtk-route-gtk4-filedialog-calls-through onto origin/develop (no-op, already current). cargo test --no-default-features passed (0 failures). verify-merge clean (develop-ahead: 0, no foreign commits). Ran coord merge --repo vimcode: PR #586 created and merged, issue #572 closed. develop now at 39550f9 with the #572 commit at tip.

[JDonaghy]

Coordinator: Assignment Failed

Machine: precision
Status: failed
Exit code: 1
Duration: 18m 55s

Error

Merge-prep blocked (#604): branch is missing 1 commit(s) from develop — the rebase did not bring it up to date (run git fetch and rebase onto origin/develop).