AlynxZhou
commented
5 months ago 首先，周老师完全没有搞清楚 input-method 提供了什么功能。除了传递输入法相关的数据之外，它还提供了一个特殊的窗口 role，允许指定某个 wl_surface 是输入法窗口，从而可以做到包括将它移动到正确位置，避免显示时移出屏幕，等等一系列功能，这一系列操作都由 compositor 帮你完成。
所以 input-method 和显示输入法窗口本身是紧密相关的。
这段改了。
而正是因为这一点，在 KDE 下 kimpanel 的窗口因为 plasma 本身并不是输入法进程，是无法使用这个功能的。在 KDE/Wayland 下最好的效果就是由输入法进程自己负责绘制窗口。
不太熟悉 plasma，这段删了。
最后，「IBus 自己绘制界面时也是客户端窗口之一，因此在 Overview 模式下输入法自己绘制的界面是没法使用的」 这句话显然本身就是错误的。实际上，即使当年在 X11 下面时，override_redirect 的窗口也不会和 Overview 产生什么互动，如果背景为透明时就能看到被挡住的 fcitx 窗口在背后。只要 GNOME 愿意，它就能匹配窗口并且把他拉上来（事实上也曾经有人用 extension 实现这样的功能）。
其实意思就是 GNOME 不支持这种，我觉得也算可以理解，毕竟一开始就设计成输入法界面包含在 GNOME Shell 进程里面，就没什么动力再去给输入法的客户端窗口做单独的匹配处理了。就算是换成我自己，也懒得多做这个支持……
这里本来就是不同技术路线的问题，并不是「不能做到」的问题。
没有说不能做到的意思，我自己都想过如果要写 input-method 该在哪些地方下手了，但是想想具体要做的就觉得工作量太大了（关于输入法单独的 wl_surface 这个显然要单独写一大堆代码处理，一个是我对目前的现状感到满意自然没动力写，另一个是如果我是维护者我也不会有积极的意愿去合并这些额外的代码……）。就是因为一开始选择的方式不同，既然在 GNOME Shell 里面做输入法界面使用体验还不错，那再去做另一种就显得非常麻烦了……
总之我其实是比较容易安于现状的人，和 text-input-v1 这个确实是没有就影响体验的地方不一样，我自己是觉得目前够好了没必要去做这个，然后特别是 Fcitx 一头可以接 IBus 接口一头可以接 kimpanel 扩展，别人问我我只会说这么用然后心怀感激。
整个的意思还是说我觉得 GNOME 这个输入法架构用着还行，也不至于像有些人表达的没有 input-method 就多大逆不道一样，因为从他技术选型上来说确实是用不着这个。而且毕竟实际上活着的也就 IBus 和 Fcitx 这俩输入法了，现状是都能用（当然这个还得再次感激你哈哈）。
catscarlet
周老师讲自己不懂的东西还要顺带维护一手GNOME的样子真是丑陋呢。
首先，周老师完全没有搞清楚 input-method 提供了什么功能。除了传递输入法相关的数据之外，它还提供了一个特殊的窗口 role，允许指定某个 wl_surface 是输入法窗口，从而可以做到包括将它移动到正确位置，避免显示时移出屏幕，等等一系列功能，这一系列操作都由 compositor 帮你完成。
所以 input-method 和显示输入法窗口本身是紧密相关的。
而正是因为这一点，在 KDE 下 kimpanel 的窗口因为 plasma 本身并不是输入法进程，是无法使用这个功能的。在 KDE/Wayland 下最好的效果就是由输入法进程自己负责绘制窗口。
其次，协议的统一保证的是状态的同步。你不能要求 dbus 和 wayland 两个协议之间有什么同步关系，他们甚至都不是由同一个事件队列维护的，遑论同步。同步这件事在处理很多边角的情况是重要的，特别是在不同的窗口之间转换。
最后，「IBus 自己绘制界面时也是客户端窗口之一，因此在 Overview 模式下输入法自己绘制的界面是没法使用的」 这句话显然本身就是错误的。实际上，即使当年在 X11 下面时，override_redirect 的窗口也不会和 Overview 产生什么互动，如果背景为透明时就能看到被挡住的 fcitx 窗口在背后。只要 GNOME 愿意，它就能匹配窗口并且把他拉上来（事实上也曾经有人用 extension 实现这样的功能）。
这里本来就是不同技术路线的问题，并不是「不能做到」的问题。