Conversation
Not an operation that can be supported when we reference-count these.
|
|
||
| unsafe { Self::new(ns_view, objc_retain, objc_release) } | ||
| } | ||
|
|
There was a problem hiding this comment.
Unsure whether we should be in the business of exposing target-specific helper methods like these?
We definitely shouldn't make the AppKitWindowHandle struct be #[cfg(target_os = "macos")], because it can technically also be used on Linux with GNUStep.
I also just now realized that this links libobjc, even if never used (which would be annoying for e.g. someone running Wayland on macOS). So if we wanted to do this, we might need to gate it behind a feature flag?
| // objc_retain | ||
| retain: unsafe extern "C-unwind" fn(ns_view: *mut c_void) -> *mut c_void, | ||
| // objc_release | ||
| release: unsafe extern "C-unwind" fn(ns_view: *mut c_void), |
There was a problem hiding this comment.
We need to discuss advantages/disadvantages of storing function pointers directly vs. storing a &'static vtable like Waker does. I assume its done to keep the size of Waker down to 2 pointers? Is it worth the effort in our case?
I do find it kinda annoying that it'd introduce a new AppKitWindowHandleVTable type for most of the handles we have, but maybe that can be worked around by using tuples?
pub unsafe fn new(
ns_view: NonNull<c_void>,
vtable: &'static (
// retain
unsafe extern "C-unwind" fn(ns_view: *mut c_void) -> *mut c_void,
// release
unsafe extern "C-unwind" fn(ns_view: *mut c_void),
),
) -> Self { ... }
| // TODO: Should we store a function to get the surface pointer, or just the surface pointer | ||
| // itself? The user is required to always return the same pointer, so either option is valid. | ||
| get_surface: unsafe fn(info: *const ()) -> NonNull<c_void>, |
There was a problem hiding this comment.
Unsure whether we should use a function to get the surface, or store the surface: NonNull<c_void> directly?
I'm leaning a bit towards storing the surface pointer directly to make it clear that it can't change, but I guess it depends on whether we want vtables to keep the size down?
|
We discussed this in the meeting today, and decided that the semantics should be "the entire window state is kept alive for the duration of the reference-count (not just the surface state)", which means we're probably going to go with #207 instead. |
1 participant
Fixes #188.