Native window types

[maia-s]

I'm still looking at implementing raw-window-handle for the rust SDL bindings. None of this is critical, but I'd appreciate some help.

For macos/AppKit, SDL provides a pointer to the NSWindow with the SDL_PROP_WINDOW_COCOA_WINDOW_POINTER property, but raw-window-handle wants a NSView pointer. As far as I know getting the NSView from the NSWindow requires writing objective c code, which I'd rather not deal with, but SDL already does that - is it possible for SDL to add a property with the NSView, or is there another way I can get it?

Similarly, for ios, SDL provides a UIWindow where I need a UIView. I know nothing about objective C, but UIWindow inherits from UIView, so can I just bitcast that pointer? Is that correct?

For X11, SDL only provides native window types for Xlib, but not for xcb.

If I want to support KMS/DRM too (idk if anyone would use this) I need either a "plane" for KMS or a GBM surface. I don't know how to get those.

There's no native window property for emscripten, but I think I can get that from js

[slouken]

For macos/AppKit, SDL provides a pointer to the NSWindow with the SDL_PROP_WINDOW_COCOA_WINDOW_POINTER property, but raw-window-handle wants a NSView pointer. As far as I know getting the NSView from the NSWindow requires writing objective c code, which I'd rather not deal with, but SDL already does that - is it possible for SDL to add a property with the NSView, or is there another way I can get it?

The problem is that while windows are static to the SDL_Window, views are dynamic and can come and go.

Similarly, for ios, SDL provides a UIWindow where I need a UIView. I know nothing about objective C, but UIWindow inherits from UIView, so can I just bitcast that pointer? Is that correct?

The relationship between NSWindow and NSView is the same as UIWindow and UIView, you can't cast them, and there may be multiple views that come and go as UI changes.

For X11, SDL only provides native window types for Xlib, but not for xcb.

That's correct. I don't think we use xcb under the hood, but I think you can create an xcb window from an xwindow.

If I want to support KMS/DRM too (idk if anyone would use this) I need either a "plane" for KMS or a GBM surface. I don't know how to get those.

The GBM surface can be exposed, if it's useful.

[slime73]

As far as I know getting the NSView from the NSWindow requires writing objective c code

I think you can use the C function objc_msgSend and friends if you want to avoid compiling Objective-C code.

[maia-s]

The problem is that while windows are static to the SDL_Window, views are dynamic and can come and go.

I only need to get the "main" view of the window, i.e. the one that corresponds to the whole window. Is this also dynamic and can come and go with AppKit? (With UIKit, a UIWindow is a UIView, see below)

The relationship between NSWindow and NSView is the same as UIWindow and UIView, you can't cast them, and there may be multiple views that come and go as UI changes.

The way these are exposed are at least different. UIWindow inherits from UIView, i.e. a UIWindow is a UIView, so there's always one available, itself. See https://developer.apple.com/documentation/uikit/uiwindow . So it seems like SDL should be able to provide this one.

For NSWindow, it's different. It doesn't inherit NSView. There's a method you can call named contentView which seems to be what I want, but this returns an object managed by the objc/swift runtime. I can get a pointer from it, but once the object goes out of scope it could get dropped and invalidated before the window as far as I know, so I can't work with that. If SDL knows that this is valid for the duration of the window (or at least some defined duration), it could provide this.

The GBM surface can be exposed, if it's useful.

Yes, this would allow me to implement raw-window-handle for GBM. It's not high priority for me but it'd be a nice addition.

[maia-s]

I think you can use the C function objc_msgSend and friends if you want to avoid compiling Objective-C code.

Thank you, but this all seems very complicated. Apparently the actual signature of this function depends on the arguments given and can't even be implemented without assembly code. I found some crates for Rust that can deal with this for me if necessary, but that has issues too (see my post above)