mirror of
https://github.com/ghostty-org/ghostty.git
synced 2025-05-04 15:28:37 +03:00

Fixes #366 The comment in the Swift code explains what was happening here: > I don't know if this is the right place, but because of WindowAccessor in our > SwiftUI hierarchy, we have a reference cycle between view and window and windows > are never freed. When the window is closed, the window controller is deinitialized, > so we can use this opportunity detach the view from the window and break the cycle. An alternate solution would be to make our reference back to the window "weak" but we appear to not be able to do that with SwiftUI property wrappers such as `@State` and `@Binding` and so on.
25 lines
1.0 KiB
Swift
25 lines
1.0 KiB
Swift
import Cocoa
|
|
|
|
class PrimaryWindowController: NSWindowController {
|
|
// This is used to programmatically control tabs.
|
|
weak var windowManager: PrimaryWindowManager?
|
|
|
|
// This is required for the "+" button to show up in the tab bar to add a
|
|
// new tab.
|
|
override func newWindowForTab(_ sender: Any?) {
|
|
guard let window = self.window as? PrimaryWindow else { preconditionFailure("Expected window to be loaded") }
|
|
guard let manager = self.windowManager else { return }
|
|
manager.triggerNewTab(for: window)
|
|
}
|
|
|
|
deinit {
|
|
// I don't know if this is the right place, but because of WindowAccessor in our
|
|
// SwiftUI hierarchy, we have a reference cycle between view and window and windows
|
|
// are never freed. When the window is closed, the window controller is deinitialized,
|
|
// so we can use this opportunity detach the view from the window and break the cycle.
|
|
if let window = self.window {
|
|
window.contentView = nil
|
|
}
|
|
}
|
|
}
|