You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Each OS has their own way of describing a Window ID, and that's managed in Tao's WindowId struct with the different implementations depending on the OS being compiled for. After doing some digging, some of the platform-specific WindowId structs expose their numerical ID (like macOS), while some don't (like Windows). While writing a cross-platform wrapper, and trying to hook into the event loop, I am unable to access the underlying numeric ID, despite them all fitting into a 64bit type:
Win: isize, max 64bits,
Mac: usize, max 64bits,
Linux: u32, max 32 bits,
iOS: *mut Object, which looks like a pointer, so max 64bits? (Please correct me if I'm wrong!)
Android: doesn't have a numeric ID, but I guess the pointer to the WindowID struct is enough, therefore max 64bits?
Describe the solution you'd like
Ideally, I'd like the be able to access the numeric ID to have a reference to it in JS.
Describe alternatives you've considered
An alternative is to use a Hasher because all the implementations derive(Hash). The problem with this, is that I need to send a window ID with quite a few events, and therefore hashing the same thing every time (while it might get cached by the processor) is actually pretty intensive to calculate.
Would you want to assign yourself to implement this feature?
Yes
I would give each struct a way of providing their numeric ID, probably through a getter, and have the Tao API call upon those. I don't know if there's a safer way to do it, though.
No
The text was updated successfully, but these errors were encountered:
We are currently in the middle of trying to minimize the differences between tao and winit hoping to someday switch wry/tauri to use winit directly and to me this feels like an unnecessary change that could potentially get reject upstream so I'd rather not implement it this now.
I think if you are building a wrapper then you already have a Window store and you need to generate ids in order to store the window and use it later; in this case I'd recommend generating your ids, take a look at this simple Counter struct in druid repo that could be used to generate unique ids.
That's a shame! Is there a roadmap or Project that I can track for the conversion? I'm curious now, and I'd expect it might change the way that my wrapper might integrate...
Is your feature request related to a problem? Please describe.
Each OS has their own way of describing a Window ID, and that's managed in Tao's
WindowId
struct with the different implementations depending on the OS being compiled for. After doing some digging, some of the platform-specificWindowId
structs expose their numerical ID (like macOS), while some don't (like Windows). While writing a cross-platform wrapper, and trying to hook into the event loop, I am unable to access the underlying numeric ID, despite them all fitting into a 64bit type:isize
, max 64bits,usize
, max 64bits,u32
, max 32 bits,*mut Object
, which looks like a pointer, so max 64bits? (Please correct me if I'm wrong!)Describe the solution you'd like
Ideally, I'd like the be able to access the numeric ID to have a reference to it in JS.
Describe alternatives you've considered
An alternative is to use a
Hasher
because all the implementationsderive(Hash)
. The problem with this, is that I need to send a window ID with quite a few events, and therefore hashing the same thing every time (while it might get cached by the processor) is actually pretty intensive to calculate.Would you want to assign yourself to implement this feature?
The text was updated successfully, but these errors were encountered: