xwidgets 添加 Xembed 就争吵了很久，最好别冒险。
X11 reparent window是UNIX时代就存在的功能，自由软件和外部进程窗口合并，不存在源码级别联系，要不mplayer和vlc支持不同图形库的功能就不要做了。
XReparentWindow 从古至今是用来实现控件的，与外部进程合并窗口要用 Xembed。
我要讨论的是，为啥因为一些奇奇怪怪的理由去改现有窗口的xid？为了一些workaround去新建窗口的做法合适吗？
目前没有找到更好的办法。
还是我上面观点，为了workaround新建窗口不是改变现有emacs窗口xid的理由。
请问 gtk_window_new 如何保留之前的 XID？
EAF是为了加入Emacs master分支吗？EAF用一个 window id 有啥冒险不冒险的？
那只是你个人的观点，XReparent是Linux图形桌面和窗口管理器常用技术，ffmpeg、mplayer、VLC等一系列开源软件都在用，XEmbed和XReparent爱用啥用啥。
没有找到更好的方式，就要Workaround？
Emacs的一个frame已经启动了，用的好好的，为啥要新建一个窗口？ 就是为了Workaround解决你遇到的问题？
你为什么认为自己就是对的，自己要解决的任务才是重要的，别人的都是不重要的？按照Emacs的设计没有哪个API一直都是稳定API, Emacs的最佳的做事方式是，给每个人更多的选择，爱用那个用哪个。
EAF只是一个外部进程，通过X11技术粘贴到Emacs窗口上，和Emacs窗口独立进程，源码没关系，实现没关系，就是用X11的标准协议，碍你啥事了？ 你要去操作非Emacs进程窗口的事件，同时还要为了Workaround去新建窗口，让EAF和任何外部程序都没办法获取稳定的XID。
你觉得你的做法本身是不是欠考虑？ 还一本正经的告诉我新版会导致EAF没法用。
Emacs是属于社区的，不是你一个人的，讲点道理好不好？ 不要以个人观点来代表Emacs！！！
没有找到更好的方式，就要Workaround？
workaround 总比死机好。
你为什么认为自己就是对的，自己要解决的任务才是重要的，别人的都是不重要的？按照Emacs的设计没有哪个API一直都是稳定API, Emacs的最佳的做事方式是，给每个人更多的选择，爱用那个用哪个。
首先，如果想用 reparent，你可以不开启 XInput 2，默认会处于关闭状态。 顺便举个例子：当时 Emacs 启用 double buffering 时怎么没人抱怨不能直接往 frame 的 Drawable 上绘画呢？
你这种 “自己是对的就好，破坏API到底影不影响别人，你根本就不关心” 的做法已经和Emacs这么多年让用户更多选择的基本原则相冲突了。
我不想再和你讨论，道不同。
如果你因为那些站不住脚的理由让 window-id 无法稳定使用，我们就在Emacs邮件列表上见吧，让整个Emacs社区大家一起讨论，“为啥遇到bug不去修根本问题，而是要采用新建窗口来绕过” 这种做法到底对不对吧。
我没时间修根本问题，补丁当然会很受欢迎。
全篇读下来没有看到 @oldosfan 正面回答任何一个问题，只是将自己拆东墙补西墙把功能稳定的feature拆掉作为workaround的行为跟Emacs的发展直接挂钩，并声称一个还在持续开发的自由软件新版本的代码不会改变？这是啥，只要是自己（或许会）push的代码就必须保留吗，Emacs姓Lu了？没有时间修复根本问题可以选择先放着不修也别破坏完好的功能啊？？
重点是，你可以不选择使用 XInput 2，目前还是开发中的功能，默认没有开启，肯定会出现各种问题，需要各种解决方式。
请注意我还没有 push 关于改变 XID 的代码，只是说未来可能会改变，也没有说 EAF 一定会受到触摸代码的影响。
一、最近在做关于触屏支持的工作，Emacs 会对所有的 child window（包括被 reparent 的 QWindow）运行 XISelectEvents，Emacs 29 的 XInput2 用户可能发现 EAF 无法使用，如果出现这种问题，请说一声。
因为你欠考虑（在未来可能会）直接push的代码就逼着其他人不用一整个大feature吗？你为什么不能选择三思而后行呢。
说到底，你就不能正面回答一下上面的问题吗？能不能收起自己的ego？
你现在没push没问题，你只是propose了一个方案，于是懒猫在这里对你的proposal提出了意见和疑问，可是你避重就轻回避他提出的疑问，多次强调代码不会改变，我没时间修根本问题，不想用就别用，你好歹听一下别人的意见好吧。
我已经正面回答了上面的一切问题。
Core Input 代码都没有遭遇到改变，EAF 可以像往常一样正常工作，而 Emacs 开启 XInput2 时会改变内部处理 event 的框架，其他像 EAF 一样依赖 Emacs 内部结构的程序必然需要改变。（和 EAF 在 pgtk 下需要改变同样的原因）
编译后也可以在环境中添加 `GDK_CORE_DEVICE_EVENTS=1’ 来关闭 XInput 2。
最好不要把 --with-xinput2 想成 X 上的附加品，而想成其他的窗口系统。
鉴于后续讨论内容已与原主题偏离，特此分割至新主题
代码不会改变的原因是没有可用的改变方式：如果你用 XReparentWindow 把窗口贴到启用 XI2 的 Firefox 上，也会出现类似的问题。如果不使用触摸屏应该不会出现问题。
顺便说一下，我原本发 PSA 的原因就是想收到反馈，问问用户有没有出现问题，结果收到“能否别给开发者创造一些障碍”这样的回答。
触摸屏问题，本来希望会有人用 master 测试 EAF 有否受到影响，如果受到了影响我尽量解决，而动态改变 window-id 纯粹是为了讨论才提到的。
oldosfan的本意是xinput2这个编译选项加了以后EAF就没法稳定获取window-id了。
但是去掉xinput2编译选项后，EAF依然可以正常工作，虽然emacser会面临EAF和xinput2二选一的问题。
开源社区本身就是一种发展过程，只要始终有选择就是好的事情，我相信oldosfan有一天会找到解决xinput2现有bug，同时又不workaround的完美解决方法的，一切交给时间吧。
我前面认为emacs29彻底无法稳定获取window-id导致EAF无法使用，后面oldosfan也清晰的说明只是影响xinput2分支。
既然讨论清楚就行了，如果因为误解导致不合适的过程和行为，我向oldosfan道歉。
看官们就当上面是一种激烈的社区讨论方式吧。
或许是因为我中文不好，但我真没看到，所以才打了这么多字。你要不像我刚才那样，以Q&A的方式把懒猫的Q和你的A一行一行，字字句句quote出来？
早说嘛，这才是我能看到的第一个正面回答 
目前EAF“必然”需要改变的前提是你apply完你propose的这个workaround破坏掉原本一切正常的window-id吧？至少到目前为止你没说过还有其他哪些问题呀。
对呀，所以按理来说别人提出意见，你好好回答就行了，你是大神，懒猫也是大神，都是这方面的专家，发现proposal出现了不理想的sideaffect，一起坐下来好好讨论如何找到真正双赢的解决方案，不要“我就不改代码，没时间修，你不想用就不用”，这样productive吗？我都有点看不下去了，才掺和进来催你正面答复。
Don’t get so defensive, always assume good intentions.
懒猫这话确实有点激动了。
好消息，全屏死机这个问题只有 GNOME 41.1 才会出现，更新到 41.2 后就消失了，所以只需要加到 etc/PROBLEMS 中
看上去挺复杂, emacs有没有可能把后台和显示分开? 类似于neovim? 显示要考虑得东西太多了, 而后台就不一样, 可以很专注. 这样核心开发人员可以专注于后台核心功能
其实 Emacs 已经把后台和显示分开的很不错了，所有的操作都会通过 frame parameter hook、redisplay interface、font driver 和 `struct terminal’ 进行，核心显示代码不需要关注前端细节，只需要使用这些 hook
未来有没有可能让显示和后台跨进程? neovim目前好像是这样, 后台只关注核心功能以及terminal显示, 其他GUI的东西全部不在核心里面, 在外部进程实现. 两者之间有一套RPC协议. 这样核心和GUI的维护完全分离, 而且可以支持第三方的GUI. 核心工作量将会大大减轻.