引言
KDE Plasma的窗口规则功能非常强大。
它可以让指定应用自动：
- 出现在固定位置
- 使用固定尺寸
- 最大化
- 打开在指定屏幕
- 进入特定虚拟桌面
- 保持置顶
- 禁止改变大小
在X11环境中建立的大量窗口规则，切换到Wayland后可能出现：
- 完全不生效
- 匹配到错误窗口
- 位置偏移
- 尺寸过大
- 窗口跑到屏幕外
- 同一个应用有时生效、有时不生效
原因通常集中在两个方面：
窗口身份变化
＋坐标系统变化一、X11中的WM_CLASS
X11窗口通常具有 WM_CLASS 属性。
可以使用：
xprop WM_CLASS点击窗口后获取类似：
WM_CLASS(STRING) = "browser", "Browser"KDE窗口规则会使用这些信息识别应用。
规则文件中可能出现：
wmclass=browser
wmclassmatch=1其中精确匹配意味着窗口身份必须完全一致。
二、Wayland中没有传统WM_CLASS
原生Wayland窗口不使用X11的 WM_CLASS。
应用会向合成器提供其他身份信息，例如应用ID。KWin会将这些信息映射到窗口规则界面中，仍可能显示为“窗口类”，但来源已经不同。
因此，同一个程序可能出现三种身份：
X11版本的WM_CLASS
XWayland版本的WM_CLASS
原生Wayland版本的应用ID应用升级、切换启动参数或更换后端后，旧规则就可能无法匹配。
三、Electron和Chromium应用尤其容易变化
Electron和Chromium程序的窗口身份可能受到以下因素影响：
- Electron版本
- Ozone平台
.desktop文件名StartupWMClass- 应用启动参数
- 是否使用原生Wayland
- 是否以PWA或App模式启动
- 自定义用户数据目录
例如，同一个浏览器窗口可能分别呈现：
browser
Browser
browser-browser
自定义应用ID如果规则使用精确匹配：
wmclassmatch=1任何细微变化都可能导致规则失效。
四、重新采集窗口属性
Wayland下不应继续依赖 xprop 获取原生窗口身份。
更合适的方法是：
系统设置
→ 窗口管理
→ 窗口规则
→ 添加新规则
→ 检测窗口属性然后点击目标窗口。
采集时应记录：
- Window Class
- 窗口标题
- 窗口角色
- 窗口类型
- 应用名称
如果应用同时支持Wayland和XWayland，应确认当前窗口实际运行在哪种模式。
五、不要过度依赖窗口标题
窗口标题通常包含动态内容，例如：
文件名
网页标题
聊天对象
项目名称
当前目录如果规则使用精确标题匹配，很容易失效。
更合理的匹配优先级通常是：
- 稳定的应用类或应用ID
- 窗口角色
- 窗口类型
- 必要时使用标题子串或正则
- 尽量避免完整标题精确匹配
六、Wayland使用逻辑坐标
假设显示器物理分辨率为：
3840×2160缩放为：
150%逻辑桌面尺寸约为：
2560×1440Wayland下，KWin窗口位置和大小通常基于逻辑像素。
如果旧X11规则中写着：
位置：2000, 300
尺寸：1600×1200这些值可能是按照4K物理像素设计的。
迁移到1.5倍缩放的Wayland后，同样数值会被解释为逻辑像素，窗口可能变得非常大，甚至超出屏幕边界。
七、如何换算旧坐标
简单情况下，可以使用：
Wayland逻辑值
=
X11物理值
÷ 缩放倍率例如：
原X坐标 1800
÷ 1.5
= 1200原尺寸：
1500×900换算为：
1000×600但实际迁移时不建议只做机械换算，因为：
- 窗口装饰尺寸可能变化
- 应用最小尺寸可能不同
- 字体和控件尺寸可能重新布局
- 多屏排列可能变化
- Wayland应用的客户端装饰与X11不同
更稳妥的方法是在Wayland中实际摆放窗口，再让KDE记录当前几何。
八、固定位置规则的潜在问题
固定位置规则在以下情况下最容易失效：
- 外接显示器未连接
- 输出名称变化
- 主屏幕变化
- 缩放比例变化
- 屏幕旋转
- 笔记本开合
- 逻辑坐标原点变化
如果规则绑定了旧屏幕编号，应用可能被放到不存在的输出上。
对于经常切换显示器的设备，更适合使用：
- 记忆位置
- 应用初始位置
- 指定虚拟桌面
- 指定屏幕但避免固定坐标
九、规则动作类型也很重要
KDE窗口规则通常支持不同应用方式，例如：
- 应用初始
- 记忆
- 强制
- 立即应用
- 暂时强制
其中“强制”会持续覆盖用户手动调整。
迁移后如果窗口行为异常，应检查旧规则是否使用了过于强硬的动作。
例如固定尺寸使用“强制”，可能导致应用在Wayland下无法正常调整布局。
更温和的选择通常是：
应用初始或：
记忆十、原生Wayland与XWayland可能需要两套规则
某些应用在不同启动方式下可能分别运行于：
- 原生Wayland
- XWayland
两种模式的窗口身份可能不同。
如果需要同时兼容，可以：
- 使用更宽松的正则匹配
- 为两种身份分别建立规则
- 统一应用启动参数
- 固定应用始终使用同一种后端
不建议在没有确认窗口身份的情况下，盲目扩大匹配范围，否则可能误伤其他窗口。
十一、批量迁移的建议顺序
如果系统中存在大量窗口规则，可按以下顺序处理：
第一阶段：只处理高频应用
优先检查：
- 浏览器
- 文件管理器
- 终端
- 编辑器
- 通讯软件
- PDF阅读器
第二阶段：处理固定坐标和尺寸
寻找：
position=
size=以及对应规则动作。
第三阶段：检查精确匹配
重点检查：
wmclassmatch=1
titlematch=1第四阶段：清理失效规则
只有确认规则已无对应应用，或者已经由新规则替代后，才删除旧规则。
迁移期间可以暂时保留旧规则，方便回退X11测试。
十二、不要直接手工大规模修改kwinrulesrc
KDE窗口规则保存在：
~/.config/kwinrulesrc虽然可以直接编辑，但大量手工修改存在风险：
- 规则数量字段不一致
- 规则编号错位
- 动作类型配置错误
- 正则表达式失效
- 误删其他应用规则
优先使用系统设置界面逐项调整。
需要脚本化处理时，应先完整备份并进行结构验证。
结语
KDE窗口规则从X11迁移到Wayland，最容易忽略的两个变化是：
WM_CLASS不再可靠
物理像素坐标变成逻辑坐标因此，旧规则不应被简单复制，而应重新确认：
- 当前应用运行后端
- 当前窗口身份
- 当前显示缩放
- 当前逻辑几何
- 规则动作类型
对于高度定制化桌面，窗口规则迁移通常是Wayland切换中工作量最大的一部分。但只要按应用逐个采集、逐条验证，就能避免一次性重写全部配置带来的风险。