Skip to content

feat(macos): open files from Finder (Open With, double-click); macOS build check on PRs (#1589) - #1705

Merged
ZhuchkaTriplesix merged 1 commit into
devfrom
feat/macos-open-with
Oct 17, 2026
Merged

ZhuchkaTriplesix merged 1 commit into
devfrom
feat/macos-open-with

Conversation

@ZhuchkaTriplesix

Copy link
Copy Markdown
Member

Closes #1589.

Info.plist declares .sql and .sqlite / .sqlite3 / .db / .db3, but on macOS "Open With" and a double-click deliver the file as an Open Documents Apple Event, not in argv, so FileLaunchService.processLaunchArguments never saw it and the app opened empty.

Native side (AppDelegate.swift, MainFlutterWindow.swift)

  • The app installs its own handler for kAEOpenDocuments when launching starts (willFinishLaunchingNotification, the moment AppKit documents for Apple event handlers). It does not override any FlutterAppDelegate method, so it does not depend on which open-file methods that class declares.
  • Files that arrive before Dart is ready are kept; the main window attaches a querya/file_open method channel once its engine exists. Dart's takePendingFiles returns the kept ones, and from then on every new batch is sent as openFiles.

Dart side

  • MacOsFileOpenChannel.install() (called in main right after the argv files) listens to the channel and takes the launch files; it is a no-op off macOS and with a runner that has no channel.
  • Paths go through FileLaunchService.parseArgument, so only .sql and SQLite files are queued, as with argv.
  • FileLaunchService.addPendingTarget now bumps pendingRevision; MainScreen listens to it and opens files that arrive while the window is up (the startup path is unchanged).

macOS build check (new workflow). The PR checks run on Linux, so nothing compiled Swift before a release tag. .github/workflows/macos-build.yml runs flutter build macos --release on macos-latest for pull requests that touch macos/**, pubspec.* or the workflow itself (the repository is public, so the runner is free). It runs on this PR, which is the only build check the Swift here has; whether Finder really opens a file still needs a try on a Mac.

Not changed: .db / .db3 stay registered (LSHandlerRank is already Alternate, so the app does not claim them by default); the issue asked to reconsider them, which is a product decision.

Tests: the queue logic (openable paths queued with their kind, others and non-strings skipped, the revision bumped, non-lists ignored) and install being a no-op off macOS.

…t launch and while running; build the macOS app on PRs that touch it (#1589)
@github-actions github-actions Bot added bug Something isn't working P2 Medium priority / Parity & Refactoring labels Oct 17, 2026
@ZhuchkaTriplesix
ZhuchkaTriplesix merged commit 2678ce4 into dev Oct 17, 2026
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working P2 Medium priority / Parity & Refactoring

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant