Hmm, I am afraid I don’t see what role does this GdkWindow have, nor why does the code require it to be looked up from a X11 Window. In GTK4 IM context are inextricably attached to a GtkWidget, it is used to determine the focus position within the toplevel, whether it has focus or not, and many other details. That can no longer be exposed to other random processes as a handle.
Is it the case that IM interaction is done from the web process? If this is what is happening, GTK4 and Wayland will require that it is the browser process (i.e. the one creating the toplevel surface that everything gets drawn to) that does the communication with the compositor, it cannot be delegated to a third process. That requires communication between web and browser processes, so the latter can do the interfacing between the compositor and the web process through a
WebView GTK4 widget.
So the question is: what can we use as the argument to
gtk_im_context_set_client_widget() ? A function similar to
gdk_x11_window_lookup_for_display() would be super useful – for example, is it possible to obtain a
GdkSurface from Wayland’s
wl_surface and create a widget containing that surface? Then maybe that could be used with
I have the feeling you’re not just fighting against changed GTK semantics, but also against Wayland ones :). This cannot be done, for 2 reasons:
- wl_surface is just something shared between one client and the compositor, there is no global registry of surfaces, nor clients can peek/borrow surfaces made by others.
- GtkWidget is 100% a client side abstract construct. It’s again not something you can export and let other processes operate with it as an entity onscreen.
X11 is an IPC that relies on Windows being a global shared resource, Wayland no longer works that way.