Comments (5)
So, there's been a bit of back-and-forth recently about whether or not to expose HINSTANCE
in RawWindowHandle::Windows
. An HINSTANCE
is basically a handle to the application the window was created with. I was initially opposed to doing that, since similarly to ns_view
it can be derived from the hwnd
, but I've recently changed my mind about it. Exposing it isn't too much of a stretch, and it seems to give downstream users peace of mind when they don't have to reach into the platform-specific documentation to get a field they need to initialize a vulkan surface or whatever it is they need to do. After all, understanding the platform-specific APIs is largely the job of the people abstracting around the windowing APIs. I feel like ns_view
is in a similar sort of territory.
If somebody submits a PR adding ns_view_controller
and ns_window_controller
, I'll probably accept them. If not, stuff will remain as-is. I don't think there's any harm in exposing a little bit more than necessary, and I don't really feel like engaging in an argument about it, since it's mostly a matter of "what design principles do you think matter most".
from raw-window-handle.
I don't know if I really agree, as this leaves more room for bugs caused by implementers of the RawWindowHandle trait, but it's not really my call to make.
If you're keeping it, I strongly feel that the documentation should note which view it is precisely. as it is, it's just some view associated with the window. The contentView is probably the most obvious choice, but isn't the only one. (Additionally, if a user happens to hear they need to pass the window's contentView into something, they probably will have to look up and verify that the view they have is the contentView -- I would do this, at least).
It's also possibly worth noting that NSWindow are safe to use from whichever thread you want, but the NSView is a main-thread-only type (e.g. NSWindow is send, NSView isn't and also has a special relationship with the main thread). I don't know if this matters here, though -- probably not as MacOSHandle isn't send (admittedly, it not being send is not enough for it to be sound to use the NSView, but only unsafe code can do anything meaningful with it anyway, so that's possibly fine).
from raw-window-handle.
If you're keeping it, I strongly feel that the documentation should note which view it is precisely. as it is, it's just some view associated with the window. The contentView is probably the most obvious choice, but isn't the only one.
What sorts of bugs could happen as a result of not doing that? If users can associate multiple NSView
s with a particular window, it seems useful to allow implementors to specify the exact view they're referring to. I'm not inclined to take that flexibility away without good reason.
from raw-window-handle.
Audio plugins on macOS receive (or are expected to return) an NSView *
which is independent of any particular window and which will not necessarily (in fact, rarely) end up as the contentView
.
Removing the NSView *
would break our use case irreparably.
from raw-window-handle.
Removing the NSView * would break our use case irreparably.
Sold.
from raw-window-handle.
Related Issues (20)
- `v0.6` release planning HOT 6
- Type-system relationship between `HasRaw*Handle` and `Has*Handle` traits HOT 3
- Does `RawWindowHandle` need to be `Copy`? HOT 3
- Should X display/connection handles be nullable? HOT 4
- Proposal: Remove `Copy` from `RawDisplayHandle` HOT 3
- Proposal: Make the error type implementor-selectable? HOT 2
- Follow the Rust API Guidelines HOT 2
- Take `self` instead of `&self` in raw window handles? HOT 9
- Figure out missing display handle implementations HOT 6
- Add tests for Rust subleties HOT 2
- Add relevant categories to `Cargo.toml`
- Improve documentation
- Question: Why are we exposing canvas elements instead of just any node? HOT 2
- What is the right way of handling web handles? HOT 2
- Add a bitset that allows libraries to state what types of raw window/display handles are supported HOT 1
- Add safe constructors for display and window handles HOT 3
- Remove `WebWindowHandle`? HOT 2
- Make safe `WindowHandle` s to imilictly ref-count HOT 27
- Info about sdl HOT 2
- Support DirectFB in RawWindowHandle and RawDisplayHandle? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from raw-window-handle.