Merge platform-specific handles into Raw*Handle#214
Conversation
| /// let handle = RawWindowHandle::new_weboffscreencanvas(index as usize); | ||
| /// # } | ||
| /// ``` | ||
| pub fn new_weboffscreencanvas(obj: usize) -> Self { |
There was a problem hiding this comment.
Naming scheme? I don't like this name, but new_app_kit / new_ui_kit also sounds kinda weird (though I guess less weird).
There was a problem hiding this comment.
Moved some of it to #217, the name is now new_wasm_bindgen_offscreen_canvas.
There was a problem hiding this comment.
I can see the argument for omitting new, I think it makes sense for the DisplayHandle helpers, I'm not convinced that it makes sense here?
Then again, my main argument against it would be if we had more methods on RawWindowHandle, then it'd feel like an accessor.
E.g. RawWindowHandle::ns_view(&self) -> Option<NonNull<c_void>>.
There was a problem hiding this comment.
Alternatively maybe from_ui_kit or with_ui_kit?
Only precedent for new_* in the standard library is the unstable new_in methods for allocators. I'm not aware of any constructor methods in std that don't contain either new, from or with though?
| /// # use raw_window_handle::RawDisplayHandle; | ||
| /// let handle = RawDisplayHandle::new_uikit(); | ||
| /// ``` | ||
| pub fn new_uikit() -> Self { |
There was a problem hiding this comment.
Do we need this when we have WindowHandle::uikit(), and you could just get it from WindowHandle::uikit().as_raw()?
madsmtm
force-pushed
the
madsmtm/no-platform-handles
branch
2 times, most recently
from
94a09de to
dafd51f
Compare
madsmtm
force-pushed
the
madsmtm/no-platform-handles
branch
from
dafd51f to
56df843
Compare
madsmtm
force-pushed
the
madsmtm/no-platform-handles
branch
from
56df843 to
3b98248
Compare
| /// | ||
| /// ## Thread-Safety | ||
| /// | ||
| /// WASM objects are usually bound to the main UI "thread" belonging to the |
There was a problem hiding this comment.
| /// WASM objects are usually bound to the main UI "thread" belonging to the | |
| /// Wasm objects are usually bound to the main UI "thread" belonging to the |
4 participants
Implements the idea discussed in #178 (comment).
Benefits:
Cons:
Win32WindowHandleSend + Sync#209 are now documentation-only (since there isn't a type to attach theSend/Syncimpl to). Dubious of how much value this was to begin with though.hinstanceorvisual_idafterwards.Fixes #178.
Replaces #204 and #194.
Makes #195 less of a problem.