Description
Hey folks,
I need a feature in Tauri, and I am attempting to work my way upstream through the libraries which Tauri builds upon.
Context
I need Tauri/Tao windows to behave like NSPanel
in macOS. NSPanel
is not part of the core-foundation/cocoa
library, wherefore I am working to contribute there (core-foundation/#511). The change is relatively straightforward and has already been tested successfully. 👌🏻
I am now investigating how Tao
is working with the cocoa
crate to instantiate windows. And happened to find a code block from 5 years ago [❗Implemetation today] that seems to actually subclass NSWindow
introducing the class TaoWindow
. For this subclass, the methods canBecomeMainWindow
and canBecomeKeyWindow
are overwritten to always return yes. Strangely, this is the default behavior of NSWindow
🤔 .
Q1: Is Tao here actually subclassing NSWindow overwriting default behavior? Or is it just potentially rewriting responses coming from macOS when calling the methods listed there?
Goal
I want to help make the contribution needed to allow Tao to spawn views as either NSWindow
or NSPanel
.
Solution
Because of the questions I wrote about above, it is unclear how to proceed. Early investigations made me consider introducing a new field in PlatformSpecificWindowBuilderAttributes
to spawn a window in either an NSWindow
or NSPanel
. Theoretically, the code change would be minimal if the underlying core-foundation/cocoa
library provides this class. NSPanel
shares all methods of NSWindow
, wherefore no breaking changes would be introduced. NSPanel
introduces three additional methods which, for the time being, could be just invoked directly on the ns_window()
.
If I get some guidance on how to conceptually introduce such changes, I'm offering to make the contribution myself. 🤓
Metadata
Metadata
Assignees
Type
Projects
Status