Re: Removing the `window-id' frame parameter on non-Core Input platforms

[Akira Kyle]

On Fri, Dec 17, 2021 at 10:31 PM Po Lu <luangruo@yahoo.com> wrote:
>
> The only platform where it is useful is X with Core Input, where third
> party programs can use it to manipulate a frame's X Window.
>
> This is safe on Core Input, but on XInput 2 I'd like the freedom to
> change the underlying X window of a frame after it is created to work
> around some difficult GTK related problems, which will make continuing
> to support the `window-id' parameter unreasonable.  Touch event tracking
> on XInput2 also requires that no non-Emacs code modify a window created
> by Emacs to work correctly.
>
> On non-X platforms, `window-id' is just a pointer which is even more
> useless, so I'd like to make this code in frame.c conditional on
> HAVE_X_WINDOWS && !HAVE_XINPUT2:
>
>   w = (uintptr_t) FRAME_NATIVE_WINDOW (f);
>   store_in_alist (alistptr, Qwindow_id,
>                   make_formatted_string (buf, "%"PRIuMAX, w));
>
> Does that look OK to you?
>

emacs-webkit uses the pointer obtained via 'window-id' on pgtk builds
to help identify the correct gtk container widget containing contents
of the emacs frame that should become the parent of the webkit widget.
It's a bit of a hack but would be potentially more difficult without
this pointer.

I also know that EAF uses the 'widow-id' parameter on x+gtk builds in
order to allow Qt widgets to be reparented onto emacs frames.

Also a slight tangent, but Po, do you plan to make xwidgets work on
pgtk? I'm wondering that since you've been trying to revive the
xwidget code and fixed the flickering issues on x+gtk, that xwidgets
are looking more like they are here to stay as a potentially
non-experimental feature? If that's the case, then I think I'd like to
then just integrate the work I've done on emacs-webkit into a pgtk
version of xwidgets? I think one of the key differences between the
codes are the osr versus one-to-one buffer-webkit view models.