rust-windowing/raw-window-handle

Add a type for a more generic window

notgull opened this issue · 3 comments

I'm writing a GUI framework that may use breadx, which is an X implementation not based on either Xlib or XCB, but written by hand. I'd like this GUI framework to be able to return RawWindowHandle for use in e.g. wgpu.

However, I would be unable to return a RawWindowHandle from my GUI instance if it is using breadx. I could adapt this by returning an Option<RawWindowHandle> instead of a RawWindowHandle. However, this would mean that I couldn't implement HasRawWindowHandle for this system, unless I want the implementation for that to panic when breadx is used.

I was thinking that this crate could add a more generic window handle, like this:

struct GenericHandle {
    display: Box<dyn Any>,
    window: usize,
}

Although I imagine there's a better way of doing this.

Unfortunatelly you won't be able to achieve so with e.g. wgpu.

The main issue with custom rust based raw window handles is that you don't have an ability to initialize backend surface out of them. The only thing you can use your custom backend for is software rendering with your own implementation of everything related.

To make your generic handler being actually useful for something like wgpu, you'd need to commit add implementation for your particular surface handler into mesa. Which I doubt you will.

In general I don't see much use for those, since those are not applicable to underlying system API.

And if the platform would go into mesa it must have a C ABI iirc, so you'll be able to express your custom handler with pointers.

In general, I understand that the need for something like that might be required, but in reality I'm not sure there's any value out of them or you can do anything with them.

I'm aware. Even if the end result is "it doesn't do anything useful", I'd still like the ability to return something for esoteric platforms.

Now that I think about it, perhaps a ZST type would be more appropriate for this use case.

I'm no longer doing this. This would probably be solved by #104 or, more realistically, making the traits return Result.