Closed A7R7 closed 10 months ago
可以中文解释一下吗?没看懂啥意思
我刚刚在本地测试了这个补丁, 这个补丁合并后, 在 Gnome XWayland 环境下, 单显示器单Emacs Frame的情况下, sort-tab 无法显示。
可以中文解释一下吗?没看懂啥意思
抱歉,我也觉得我写的令人难以理解。我觉得从bug现象的角度出发更容易理解,而不是从修复的角度。
在hyprland下,sort-tabs和cursor-animations的绘画有偏移,而window-borders却绘制在了正确的地方。
(holo-layer-get-emacs-frame-info)
调用了(frame-position)
这个emacs内置函数,这个函数在wayland桌面下是有问题的,会因此导致sort-tabs,cursor-animations等需要读取emacs-frame坐标的插件出现绘画偏移。
但是,window-borders绘制的却没有问题,为什么呢?这是因为window-borders同时读取了emacs-frame坐标和emacs内window坐标,并且把这两个坐标相加得出应该绘制的坐标。然而emacs-frame坐标是有问题的,在hyprland下是(0,0),之所以绘制结果没问题,是因为其读取的emacs内window坐标被补丁(holo-layer--get-frame-coordinate)
加上了偏移值,这个偏移值正好是正确的emacs-frame坐标。简而言之,emacs-frame坐标上缺失的数值被emacs内window坐标加了回来。
emacs内window坐标,是由(holo-layer-get-window-info)
返回的。如果我们认为(holo-layer-get-window-info)
本意是返回emacs内window相对emacs-frame的坐标,那么上面的补丁就不应该加在这里,而是加在(holo-layer-get-emacs-frame-info)
。这样既不会影响window-borders,也能修复sort-tabs和cursor-animations的偏移。
简而言之就是把(holo-layer-get-window-info)
里的补丁转移到(holo-layer-get-emacs-frame-info)
我刚刚在本地测试了这个补丁, 这个补丁合并后, 在 Gnome XWayland 环境下, 单显示器单Emacs Frame的情况下, sort-tab 无法显示。
那我可能是搞错了一些东西,等一下我看看
原来我读cons用cdar了,犯了一个低级错误。现在我可以在gnome-xorg和hyprland上同时正常运行了,而且是多显示器
补充:holo_layer.py 是以全屏模式启动的。但是hyprland下一个窗口的全屏会使得其所在workspace下其他窗口全部不渲染,就看不见emacs了。所以需要阻止holo_layer.py全屏,在hyprland.conf加
windowrulev2 = nofullscreenrequest, title:^(holo_layer.py)$
不过正因为hyprland的这一特性,emacs全屏后就看不到holo_layer.py了
补充:holo_layer.py 是以全屏模式启动的。但是hyprland下一个窗口的全屏会使得其所在workspace下其他窗口全部不渲染,就看不见emacs了。所以需要阻止holo_layer.py全屏,在hyprland.conf加
windowrulev2 = nofullscreenrequest, title:^(holo_layer.py)$
不过正因为hyprland的这一特性,emacs全屏后就看不到holo_layer.py了
我早上测试了, sort-tab坐标正常了, 我因为不用 hyprland, 所以没看懂你最后这句话, 这个补丁可以合并还是要再等一等?
所以没看懂你最后这句
简单的说,hyprland上同一个workspace在有一个窗口全屏后其他窗口都会变透明。所以holo_layer全屏了就看不见emacs,emacs全屏了就看不见holo_layer。
不过我后来想到,可以让emacs和holo_layer都伪全屏来共存
这个补丁可以合并还是要再等一等?
我觉得可以合并,合并后hyprland用户使用holo_layer应该不会有什么大问题了,至于其他小问题可以之后再修(
感谢补丁
It is a little complicated.
Let me first point out the problems
The emacs built-in function
(frame-position)
(that are called inside(holo-layer-get-emacs-frame-info)
) have problem running on hyprland, gnome-wayland and maybe other wayland-wms. It returns (0,0) on hyprland and something else on gnome-wayland. Therefore there should be a patch.The good news is that there's already a patch,
(holo-layer--get-frame-coordinate)
. The problem is that this patch was used in(holo-layer-get-window-info)
.(holo-layer-get-emacs-frame-info)
didn't receive this patch.Therefore, the plugins that only rely on frame-info do not draw correctly. For example, sort-tabs, cursor-animations, and therefore they have an offset to the right place.
But there're plugins that rely on both frame-info and window-info, for example, window-borders. It draws at
x = frame_x + window_x
, .aka it's treating window_x as an offset on x relative to frame. Howeverframe_x
from(holo-layer-get-emacs-frame-info)
doesn't get patched,window_x
from(holo-layer-get-window-info)
get's patched (which is wrong if we treat window_x as an offset on x relative to frame). The two wrong thing add together and result in a right thing. So we get window-borders drawing at the right place!Two ways to fix this
patch
(holo-layer-get-emacs-frame-info)
, remove patch in(holo-layer-get-window-info)
. This will treat window-info as offsets relative to emacs-frame.patch
(holo-layer-get-emacs-frame-info)
, do not touch(holo-layer-get-window-info)
, remove the use of emacs_frame_info in window-borders and possibly other plugins. This will treat window-info as absolute coordinates on the desktop.Currently I choose the first way. But this fix is possible to break other stuffs on other kinds of desktops.
Fix on sort tabs
it seems that sort-tabs was not respecting
emacs_frame_x
but respectingemacs_frame_y
.