The VPNConfiguration parameter is opaque and tightly coupled to
TunnelKit. Connecting to a Profile makes infinitely more sense, beyond
simplifying the VPNManager class. Configuration building is fully
delegated to the strategy (as it has to be).
- VPNManager takes Profile and produces VPNConfigurationParameters
- VPNManagerStrategy takes VPNConfigurationParameters (abstract)
- TunnelKitVPNManagerStrategy takes VPNConfigurationParameters and
produces TunnelKitVPNConfiguration internally
* Make specific message levels a default extension
* Define Loggable protocol
* Keep track of message originator metadata
* Fix tracing of Core Data logs
* Log query on entity not found
* Make some managers concurrency-safe
- IntentsManager: @MainActor, non-shared, continuation
- SSIDReader: @MainActor, continuation
- Reviewer: main queue, non-shared
* Review wrong use of Concurrency framework
There were background thread calls e.g. in VPNToggle, because
ProfileManager was used inside a VPNManager async call.
Annotate @MainActor wherever a Task involves UI.
* Make main managers MainActor
* Apply MainActor to Mac menus
* [ci skip] Update CHANGELOG
* Set MainActor consistently on Mac menu view models
Use bundle as a means to provide Mac APIs to Catalyst app.
In order to cross the @objc wall set by the Mac Bundle mechanism,
Swift structures cannot be used directly and must be bridged
through ObjC facades.
Create NSMenu in MVVM style and install it on app launch. Make
sure to do it in AppDelegate.applicationDidFinishLaunching(),
because doing it as early as in PassepartoutApp.init() would
crash Mac code.
Use .representedObject to own view models.
With menu in place, app can be sent to background when main window
is closed. Requires multiple documents support for app not to die
instantly.
