wxWindows::GetBackendHandle() [linux/gtk?] (Issue #25787)
Ivan Baidakou
basiliscos created an issue (wxWidgets/wxWidgets#25787)Hello,
we use wxPanel as open gl canvas to visualize vtk and open cascade .
In simple case their API is like "please, give native window id, and our library will create opengl context and do all required stuff".
On windows wxWindow::GetHandle() works perfectly, but on linux/gtk it returns gtk window handle, which must be unwrapped into gdk window handle, and then unwrapped into X-window handle.
i.e. the code:
void* NativeHandle(const wxWindow* window) { auto handle = window->GetHandle(); #if defined(__WXMSW__) return reinterpret_cast<void*>(handle); #elif defined(__WXGTK20__) gtk_widget_realize(handle); // otherwise xwindow id will can be null //gtk_widget_set_double_buffered(handle, false); GdkWindow* gdk = gtk_widget_get_window(GTK_WIDGET(handle)); return reinterpret_cast<void*>(GDK_WINDOW_XID(gdk)); #endif }
It would be nice to that method natively without the need to use any GTK/GDK codes.
I can make a corresponding PR, if the proposal is generally accepted.
WBR, basiliscos.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25787)It's not obvious to come up with a nice API for this which covers all platforms including both GTK/X11 and GTK/Wayland, even https://github.com/wxWidgets/wxWidgets/blob/6f4586aa125e7e65cb9194b6dffd01415f193627/include/wx/nativewin.h#L40-L48 is not enough. If you can propose something, please do (just the API, before the PR), but hardcoding a dependency on X11 in the API definitely doesn't look like a good idea.
Personally I think it's fine to expect people who use native GTK types to write some GTK-specific code.
BTW, I am not sure it's a good idea to call gtk_widget_realize() yourself, it would probably be better to override wxWindow::GTKHandleRealized() instead.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ivan Baidakou
basiliscos left a comment (wxWidgets/wxWidgets#25787)I think returning void* is generally OK and covers all cases, meaning that client knows what it asks and will cast to final type and how to deal with it.
It is not required to expose its native type (i.e. to include gtk/gdk headers, again), it is enough just forward it further.
Here are opencascade abstraction for it:
#ifdef _WIN32 typedef void* Aspect_Drawable; /* HDC under WNT */ #else typedef unsigned long Aspect_Drawable; /* Window or Pixmap under UNIX */ #endif /* _WIN32 */ #endif /* _Aspect_Drawable_HeaderFile */
and VTK (see https://vtk.org/doc/nightly/html/classvtkRenderWindow.html#a92c406964cb9b9293d8eb178bf691200)
void SetWindowId(void*) override {}
So, the proposed API is like following:
void* wxWindow:GetNativeHandle() const;
However, as there can be multiple layers, it can be generalized further like:
enum class NativeHandleType { #ifdef _WIN32 win32_window_handle, default_handle = win32_window_handle #else if GTK gtk_handle, gdk_handle, x_window_handle, wayland_handle, default_handle = gtk_handle #MAC_OS_X // something here #endif } void* wxWindow:GetNativeHandle(NativeHandleType = NativeHandleType::default_handle) const;
What is related to realized handle, i.e. to allow return null if needed, the additional parameter can be passed, i.e.
void* wxWindow:GetNativeHandle(NativeHandleType handle_type = NativeHandleType::default_handle, bool ensure_realized = true) const;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25787)Returning void* doesn't seem like a great API. You'd also still need to use some extra code to know what this pointer is, i.e. if it's a XID or Wayland surface or whatever else.
You're showing examples from OpenCascade which doesn't seem to support Wayland, so I don't see how it helps.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ivan Baidakou
basiliscos left a comment (wxWidgets/wxWidgets#25787)You'd also still need to use some extra code to know what this pointer is, i.e. if it's a XID or Wayland surface or whatever else.
I think that information can be asked via NativeHandleType. I.e. if it was asked for XID then it can be safely casted to it.
You're showing examples from OpenCascade which doesn't seem to support Wayland, so I don't see how it helps.
Yep, they don't support wayland at the moment.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25787)Using your proposed GetNativeHandle(type) still requires conditional compilation and then casting it to platform-specific type, so it still looks pretty awkward to me.
Sorry, but I don't think we want to add such API. Maybe we can do better but I just don't have time/bandwidth to think about this now.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ivan Baidakou
basiliscos left a comment (wxWidgets/wxWidgets#25787)Using your proposed GetNativeHandle(type) still requires conditional compilation and then casting it to platform-specific type, so it still looks pretty awkward to me.
yep, it is awkward in implementation, but from client point of view it looks quite general.
It is better then having 3 different methods on Linux (GetGTKHandle(), GetGDKHandle(), or GetXWindowId()).
Sorry, but I don't think we want to add such API. Maybe we can do better but I just don't have time/bandwidth to think about this now.
OK, let me know whether I can help somehow. I'll update the topic.
Anyway, is is possible to have something like
GetXWindowId(bool realized = false) -> XID
?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25787)As I said, I don't want to add X11-specific functions, you really can't just ignore Wayland any more.
I think we could add some wxWindow::GTKGetLowerLevelHandle() returning either GDK_WINDOW_XID(GTKGetDrawingWindow()) or gdk_wayland_window_get_wl_surface() but there is still a question of determining what got returned...
See also the existing wxGtkGetIdFromWidget() defined in include/wx/gtk/private/mediactrl.h.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ivan Baidakou
basiliscos left a comment (wxWidgets/wxWidgets#25787)yep the include/wx/gtk/private/mediactrl.h it is almost what is asked, except that it is not in public API :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
midrare
midrare left a comment (wxWidgets/wxWidgets#25787)Personally I think it's fine to expect people who use native GTK types to write some GTK-specific code.
This is not possible depending on your project setup. If you use a package manager (vcpkg for me), then GTK is a transitive dependency. To call GTK functions from your own code you have to link to GTK again, but the link target is not exposed by the package. So you must import GTK a second time, which won't version match with wx's GTK, and causes runtime errors when the two GTK versions try to declare the same GTK objects twice.
So it falls to wx to either expose GTK or provide these functions itself.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ivan Baidakou
basiliscos left a comment (wxWidgets/wxWidgets#25787)Yep, the intention is -- to avoid using of underlying backend lib (finding it, linking with it etc.) to get the native window id handle (for further OpenGL'lization).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25787)I can sympathize with your tools having deficiencies preventing you from using the libraries that you already have, but I still don't think that having functions returning GTK-specific types in wx is going to be especially useful in this case, as these types are mostly useful when you call other GTK functions.
Anyhow, I'm not fundamentally opposed to adding these accessors, this doesn't cost much and if people think they can be useful, why not, but we can't add something not taking Wayland into account in 2025.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ivan Baidakou
basiliscos left a comment (wxWidgets/wxWidgets#25787)Why can't there be an non-wayland-port method, the similar one as there are win32-specific and mac-os-specific methods? When there will be wayland demand of the method, it can be extended (generalized into base-class)?
I personally wait the opencascade support of wayland, at the moment they say "there are no users demand of wayland".
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.