feat: add setWillCloseHook to WindowManager Dart API - #16
Open
brennodewinter wants to merge 4 commits into
Open
Conversation
Exposes the native WindowWillCloseHook through the Dart FFI layer, matching the existing setWillShowHook/setWillHideHook API surface. Changes: - cnativeapi/bindings_generated.dart: FFI bindings for native_window_manager_set_will_close_hook, has_will_close_hook, handle_will_close, call_original_close, plus the callback typedef. - nativeapi/window_manager.dart: Dart methods setWillCloseHook, hasWillCloseHook, handleWillClose, callOriginalClose. Depends on libnativeapi/nativeapi#51 (C++ SetWillCloseHook).
pub (Flutter's package manager) does not initialize git submodules when fetching git dependencies. This left cxx_impl/ empty in the pub cache, causing iOS and macOS builds to fail with "file not found" on the C++ source files. Vendoring the C++ code directly into packages/cnativeapi/cxx_impl/ removes the submodule dependency and makes the package self-contained.
iOS had SetWillShowHook/SetWillHideHook stubs but was missing the four willClose methods (SetWillCloseHook, HasWillCloseHook, HandleWillClose, CallOriginalClose) added by the willClose-hook feature branch. This caused undefined-symbol linker errors on iOS builds. iOS has no desktop window close to intercept, so these are no-op stubs matching the existing show/hide pattern.
Flutter calls Window::Show(), Focus(), etc. from the io.flutter.ui thread, not the main thread. macOS requires NSWindow ordering/visibility operations on the main thread — calling makeKeyAndOrderFront: from another thread triggers EXC_BREAKPOINT with 'Must only be used from the main thread'. All void methods that touch window ordering, visibility, key state, frame, or dragging now dispatch async to the main queue via RunOnMainThread(). Getters stay synchronous (they read state and don't crash off-main-thread).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Exposes the native
WindowWillCloseHookthrough the Dart FFI layer, matching the existingsetWillShowHook/setWillHideHookAPI surface.Changes
cnativeapi/bindings_generated.dart: FFI bindings fornative_window_manager_set_will_close_hook,has_will_close_hook,handle_will_close,call_original_close, plus thenative_window_manager_set_will_close_hook_callback_ttypedef.nativeapi/window_manager.dart: Dart methodssetWillCloseHook,hasWillCloseHook,handleWillClose,callOriginalClose.Dependency
Depends on libnativeapi/nativeapi#51 (C++
SetWillCloseHook). The Dart bindings will resolve the new symbols at runtime once the native library with those symbols is loaded.Test plan
flutter analyze— no issues on bothcnativeapiandnativeapipackagesUse case
OciDeck needs
setPreventCloseto show an "unsaved changes" dialog before the window closes. This is the Dart-side binding for that feature.