Open YihaoPeng opened 3 years ago
已知与dde-dock
托盘图标收纳功能不兼容的wine源代码或二进制:
wine
软件包。wine64
软件包。已知与dde-dock
托盘图标收纳功能兼容的wine二进制(很遗憾我们没有其源代码,虽然按照LGPL我们应该有的。deepin-wine-patch里只是一组补丁,但原始代码+补丁+应用补丁的方法才等于LGPL规定的源代码,一组补丁只是源代码的碎片。而且它很久没更新了,我们也不知道这组补丁是否覆盖了以下所有二进制):
deepin-wine
软件包deepin-wine5
软件包deepin-wine6
软件包另一种复现方法:
while true; do killall dde-dock; done
你也可以自行测试其他有托盘图标的wine应用,只要用的不是deepin-wine
,在被dde-dock
收纳后均无法交互。
一个不太优雅但能用的缓解措施:
stalonetray
软件包:
sudo apt install stalonetray
stalonetray
程序,它会从dde-dock
处夺走wine托盘图标收纳能力:
stalonetray &; sleep 0.1; killall stalonetray
dde-dock
接管,而是直接漂浮在桌面上,并且可以正常交互。@tsic404 研究一下,我记得 deepin-wine 中也没有对这方面做啥特殊的操作
@tsic404 研究一下,我记得 deepin-wine 中也没有对这方面做啥特殊的操作
然而确实是这样的。。。 我现在就遇到了麻烦,deepin-wine不允许驱动器映射,所以我想和Windows共用比特彗星配置就不能 用原生wine的托盘则一旦关闭比特彗星就会一直待在托盘,再次启动会因为托盘已经有了就无法启动
@tsic404 研究一下,我记得 deepin-wine 中也没有对这方面做啥特殊的操作
然而确实是这样的。。。 我现在就遇到了麻烦,deepin-wine不允许驱动器映射,所以我想和Windows共用比特彗星配置就不能 用原生wine的托盘则一旦关闭比特彗星就会一直待在托盘,再次启动会因为托盘已经有了就无法启动
这个问题已经在处理了。
@tsic404 7b625b1 没有完全解决问题,它只兼容 winehq-devel,不兼容 winehq-staging。
我的测试方法:
安装 deepin 20.5,安装所有更新。
编译安装 https://github.com/winegame/dde-dock/tree/5.5.12-fix-wine-tray (带有 7b625b1 补丁的 5.5.12 版本)。
重启dde-dock
:killall dde-dock
安装Wine游戏助手:sudo apt install net.winegame.client
打开 https://winegame.net/games/wine-tray-test/ 安装“2a. winehq-devel,托盘图标无反应”和“2b. winehq-staging,托盘图标无反应”,安装到不同的目录。如果在网站上点击安装没反应,可以在Wine游戏助手内搜索:
启动2a和2b,会发现2a的托盘图标可以点击,2b的托盘图标不能点击。 同样的,带有wine-staging补丁的 lutris wine、proton 等均不能点击。
试了一下同时发送XTest和XEvent给wine托盘,然而没有效果,winehq-staging还是不能点击。
https://github.com/winegame/dde-dock/commit/ca17f4250444a767efc6341ae0da96eb076b9582
if (windowAttributes && !(windowAttributes->all_event_masks & XCB_EVENT_MASK_BUTTON_PRESS)) {
m_injectMode = XTest;
}
这个识别代码是没错的,两个都是XDirect
,但是winehq-staging
就是没反应,winehq-devel
就是有反应。
我装了 deepin 20.5 提供的 kde plasma,里面的xembedsniproxy
也有同样的问题,killall xembedsniproxy
之后winehq-staging
的托盘才有反应。
我装了 deepin 20.5 提供的 kde plasma,里面的
xembedsniproxy
也有同样的问题,killall xembedsniproxy
之后winehq-staging
的托盘才有反应。
这是这个软件在deepin的源中有问题吗?
@shenmo7192 对,看起来是因为deepin里的kde plasma太老了,xembedsniproxy其实都已经放弃维护了,新版plasma workspace直接接管了xembed托盘。我在archlinux里安装了最新版本的kde plasma,是可以正常点击winehq-staging托盘图标的。
winehq-staging是应用了一系列补丁的wine,也许可以用二分法来找一找是哪个补丁引发了不兼容。
wine-staging吗,测试就用原生wine验证了一下😂
又测出一个新Bug,补丁在高DPI(缩放大于1)的情况下没效果,好像是点击坐标给错了。只有缩放设成1才能点到。 这不影响wine-staging问题,wine-staging即使缩放设为1还是点不到。
wine-staging吗,测试就用原生wine验证了一下😂
对,可能是受到了这个补丁的影响:
https://github.com/wine-staging/wine-staging/tree/master/patches/winex11-XEMBED
并不是它,试了一下没影响。
在这里可以找到打好补丁的wine-staging源代码: https://dl.winehq.org/wine-builds/debian/dists/buster/main/source/
对了我问一下,为什么一定要用模拟鼠标点击的方法给wine发送托盘事件呢?如果wine托盘显示在dde-dock的顶层,那它不能自己收到点击事件吗?
还是说dde-dock实际上没有移动那个托盘图标,它还在原来的位置,只是被隐藏了,然后dde-dock用窗口捕捉的方法获取了它的图像显示在自己的托盘区域里?
XEmbed从字面理解,是把一个X窗口嵌入另一个X窗口。既然如此,那只要设置正确的层叠关系,应该就能让嵌入的窗口自行处理事件吧。要不然事事都让父窗口代理还不烦死了?
https://specifications.freedesktop.org/xembed-spec/xembed-spec-latest.html 我看这里写着: Smooth integration of the embedding application and embedded client in areas such as input device handling and visual feedback. 如果事事要模拟,肯定不能算是“Smooth integration”吧。
zccrs: 是后者。因为我们需要在dock上对托盘窗口做其它操作
zccrs: 如果只是简单的嵌入,让托盘窗口自己接收事件,那做不到拖拽托盘图标移动它的位置这类需求
老虎会游泳: 其实这带来了另外一个缺陷: 如果wine托盘弹出气泡通知,会显示在左上角。因为那个窗口实际上在左上角。
老虎会游泳: https://winegame.net/games/wine-tray-test/ 测试用例2a,启动后点窗口的X就能弹出在左上角。
我有一个猜想,wine-staging是不是检测到了自己的窗口被遮挡,所以不响应托盘事件(因为wine的一个重大问题就是层叠遮挡关系不正确,导致本来不应该被点击的区域收到点击事件,wine-staging可能想尝试修复)。 我想试试把隐藏托盘实际窗口的代码去掉,看看有什么变化。我找一找隐藏代码在哪里~
我有一个猜想,wine-staging是不是检测到了自己的窗口被遮挡,所以不响应托盘事件(因为wine的一个重大问题就是层叠遮挡关系不正确,导致本来不应该被点击的区域收到点击事件,wine-staging可能想尝试修复)。 我想试试把隐藏托盘实际窗口的代码去掉,看看有什么变化。我找一找隐藏代码在哪里~
尝试不成功。只要这个 m_trayInter->Manage(); 被调用,左上角的 Wine Tray Window 就会被隐藏,所以没办法做到左上角托盘和dde-dock同时显示。 m_trayInter->Manage(); 是一个 dbus 远程过程调用,看起来代码不在 dde-dock 里。 https://github.com/linuxdeepin/dde-dock/blob/c1efb0fb2d0444cb29c972f43957f1304dda6371/plugins/tray/trayplugin.cpp#L109
这个是dde-daemon提供的dbus服务,接口在dde-daemon/trayicon/traymanager_ifc.go#L41,调用了dde-daemon/trayicon/traymanager.go#L202
包括银河麒麟(UKUI)在内,所有可以和wine-staging托盘正常交互的桌面环境,都不能拖动图标。
所以我可能会尝试删除这个功能,不再对图标进行包装,改为直接嵌入,换取wine staging图标的正常点击。
又测出一个新Bug,补丁在高DPI(缩放大于1)的情况下没效果,好像是点击坐标给错了。只有缩放设成1才能点到。 这不影响wine-staging问题,wine-staging即使缩放设为1还是点不到。
20.6 内测更新后deepin-wine的托盘出现要点多次才能反馈的问题
建议做成个配置项和编译选项提交PR。其它发行版中可以直接在编译时禁掉这个功能,用deepin的时候,如果使用原生的wine,就通过修改配置禁用功能。
或者也可以检测到是非deepin-wine的程序就自动禁止拖动功能。
我的发行版是manjaro,桌面环境是gnome45,也存在这样的问题,运行由星火打包的wine微信和用proton转译的原神时这俩的托盘图标都无法交互
该问题是 linuxdeepin/developer-center#2263 的扩大。
问题现象
除了deepin-wine,其他wine(从4.0到6.16)生成的托盘图标被
dde-dock
收纳后均无法交互,左击和右击都没反应,在 deepin v20 / uos 20 的各种版本中均能复现,32位和64位wine程序的托盘图标均无法交互。但是其他桌面环境的wine托盘图标收纳功能就没有该问题,收纳后托盘图标依然可以交互。
如果结束
dde-dock
进程,让wine托盘图标单独漂浮在桌面上,此时也能正常交互。复现方法
从deepin软件源安装
wine-4.0 (Debian 4.0-2)
:用wine执行这个:https://github.com/YihaoPeng/QtTrayIconDemo/releases
右击
dde-dock
托盘中的盾牌图标,没反应。执行以下命令让
dde-dock
任务栏消失:右击漂浮在桌面上的盾牌图标,可以交互。注意它可能会被微信QQ等deepin-wine托盘图标挡住,移开才能看到。
评论
虽然deepin-wine在所有桌面环境中均没有托盘图标交互问题,但是: