There may be a mismatch between profiles and profile headers. For
example, some profiles may appear in the main list, but the same ones
may not appear in the existing profile names when adding a new profile
(and vice versa). That's because they are being fetched from different
sources. Unify that.
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 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.
Davide