Stance on higher level frameworks

[notgull]

In #105, I said that we should decide what we want to do about higher level frameworks, such as GTK, Qt, or others. However, it is difficult to know what level of abstraction to operate at. For instance, when it comes to GTK, do you provide:

• A pointer to the GtkWidget, the highest level abstraction,
• A pointer to the GdkSurface, since that's the windowing system used underneath.
• Since the underlying system window is usually exposed in some way by the framework, say that the higher level framework should just fill out the RawWindowHandle with that corresponding raw window.

Thoughts? I'm leaning more towards option #3 the more I think about it.

[kchibisov]

A general question, how such frameworks integrate with OpenGL/Vulkan, frow what I understand they have their own abstractions and you can't simply use OpenGL/Vulkan with them like you can with winit, so raw window handle for them is sort of weird?

[Lokathor]

SDL requires you to flag a window as intended for gl/vk/metal during window creation because the platform sometimes needs to know ahead of time, but otherwise leaves it up to you.

[ids1024]

What is the goal of this? Having access to the underlying X/Wayland/etc. connection could sometimes be useful with things like GTK. You could then use it to communicate with X or Wayland for various purposes. But I don't know if you could create an EGL or Vulkan context for a GTK widow without conflicting with what GTK is trying to do. In principle Wgpu could have a backend that sets up a GtkGLArea. (Apparently GdkVulkanContext exists; I guess you'd somehow use that with a custom widget?)

Probably best not to add anything like this without a clear idea of what it would be used for and how.

[notgull]

Seems like the overall opinion is "we don't need it". I'll move forwards with that in mind. Closing this issue for now.