[Bug 34631] New: 163music: shadow of windows is always on the top of desktop
http://bugs.winehq.org/show_bug.cgi?id=34631 Bug #: 34631 Summary: 163music: shadow of windows is always on the top of desktop Product: Wine Version: 1.7.2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: jactry92(a)gmail.com Classification: Unclassified Created attachment 46149 --> http://bugs.winehq.org/attachment.cgi?id=46149 the log reproduce follow this: 0. download and install 163music: "下一步(N)" -> "我接受(I)" -> "安装(I)" -> "完成(L)" And it will start up automatically after the installation; 2. There will be a login window, and shadow of it is always on the top.(as picture 1.png) You may need a white background to make it more clear.(as picture 2.png) This is a software in Chinese and I can't find a version in english. So if you need any help when you trying to reproduce it, please feel free to ping me in #winehackers or email me. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #1 from Jactry Zeng <jactry92(a)gmail.com> 2013-09-30 08:29:21 CDT --- Created attachment 46150 --> http://bugs.winehq.org/attachment.cgi?id=46150 the login window -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #2 from Jactry Zeng <jactry92(a)gmail.com> 2013-09-30 08:29:53 CDT --- Created attachment 46151 --> http://bugs.winehq.org/attachment.cgi?id=46151 the shadow which is always on the top -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=34631 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://music.163.com/api/pc | |/download/latest -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #3 from Jactry Zeng <jactry92(a)gmail.com> 2013-09-30 08:52:08 CDT --- Created attachment 46154 --> http://bugs.winehq.org/attachment.cgi?id=46154 login The main window shadow also can reproduce it. You may need a account to login it and here is a account for testing: account: winedbg(a)163.com password: winehq You can click the last button in the login window (as pciture 3.png) and login it with this account. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=34631 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #46150|the login window |picture 1 description| | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=34631 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #46151|the shadow which is always |picture 2 description|on the top | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=34631 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #46154|login |picture 3 description| | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=34631 lizhenbo <litimetal(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |litimetal(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=34631 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #4 from Jactry Zeng <jactry92(a)gmail.com> --- Created attachment 53699 --> https://bugs.winehq.org/attachment.cgi?id=53699 hack for workaround Here is a hack for it. This bug also impacts WeChat PC. It seems they use a same third party UI library(ANGLE - Almost Native Graphics Layer Engine?). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Georgy Yunaev <gyunaev(a)ulduzsoft.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gyunaev(a)ulduzsoft.com --- Comment #5 from Georgy Yunaev <gyunaev(a)ulduzsoft.com> --- I can confirm this bug is still present and affects WeChat PC. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 lilydjwg(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lilydjwg(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC| |dark.shadow4(a)web.de --- Comment #6 from Fabian Maurer <dark.shadow4(a)web.de> --- Still affectes WeChat as of wine-4.3. The hack doesn't help. To reproduce: https://mirrors.ustc.edu.cn/deepin//pool/non-free/d/deepin.com.wechat/deepin... Extract the deb, then "opt/deepinwine/apps/Deepin-WeChat/files.7z", then run "drive_c/Program Files/Tencent/WeChat/WeChat.exe" -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #7 from Fabian Maurer <dark.shadow4(a)web.de> --- Created attachment 63881 --> https://bugs.winehq.org/attachment.cgi?id=63881 Screenshot (See the rectangle on the right, it's from the login window) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|163music: shadow of windows |163music / WeChat: shadow |is always on the top of |of windows is always on the |desktop |top of desktop -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #8 from Fabian Maurer <dark.shadow4(a)web.de> --- Same issue(?) affects Radio.fx: https://club.tobit.com/radiofx/download.asp -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #9 from lilydjwg(a)gmail.com --- With wine 4.16 & 4.19 I don't have this issue with WeChat but with 4.20 it's back. I'll do a bisect later. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #10 from lilydjwg(a)gmail.com --- Sorry for the last comment, I came to the wrong bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #11 from lilydjwg(a)gmail.com --- I find that these gray shadows are actually a window. They are supposed to appear with the main windows but not aware of multiple desktops of X Window and appear on every desktop. With WeChat I also have a small info window noting about new messages 「↟X条新消息 | x」 appear on every desktop when it's shown. I can use xwininfo to get the id of the shadow window and use xdotool windowunmap wid to make them disappear (but they'll reappear when I minimize and restore the WeChat window). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Zhiyi Zhang <zzhang(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang(a)codeweavers.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #12 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- Created attachment 67509 --> https://bugs.winehq.org/attachment.cgi?id=67509 patch Could you try this patch? I'm not sure if this breaks other applications. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #13 from lilydjwg(a)gmail.com --- The patch doesn't work well for me with wechat. There is no longer shadows shown on every desktop, but there is an unresponsive window covering wechat windows. I can manually move away the unresponsive window and use the window underneath, but I can't get rid of it. The unresponsive window appears above the login window, the chat window and the right-click menu of the tray icon. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #14 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- (In reply to lilydjwg from comment #13)
The patch doesn't work well for me with wechat. There is no longer shadows shown on every desktop, but there is an unresponsive window covering wechat windows.
I can manually move away the unresponsive window and use the window underneath, but I can't get rid of it. The unresponsive window appears above the login window, the chat window and the right-click menu of the tray icon.
What window manager are you using? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #15 from lilydjwg(a)gmail.com --- I'm using Awesome 3.5.9. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 GuHua <renyuneyun(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |renyuneyun(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Mark <mark(a)doyle.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mark(a)doyle.ch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Pei-Tang Huang <tangtheone(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tangtheone(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Felix Hädicke <felixhaedicke(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |felixhaedicke(a)web.de -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #16 from Fabian Maurer <dark.shadow4(a)web.de> --- Also affects LINE (https://desktop.line-scdn.net/win/legacy/win7or8/LineInst.exe) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 kuletco(a)qq.com <kuletco(a)qq.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kuletco(a)qq.com --- Comment #17 from kuletco(a)qq.com <kuletco(a)qq.com> --- kUbuntu 20.04.3 has the same problem. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hytzongxuan(a)gmail.com --- Comment #18 from Jactry Zeng <jactry92(a)gmail.com> --- *** Bug 46915 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Knecker <l4vebs1mx(a)relay.firefox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |l4vebs1mx(a)relay.firefox.com --- Comment #19 from Knecker <l4vebs1mx(a)relay.firefox.com> --- I also experience this with PDF X-Change Editor in Arch (Manjaro, running KDE Plasma and Wine latest stable). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 fhb33435w(a)postedmail.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fhb33435w(a)postedmail.net --- Comment #20 from fhb33435w(a)postedmail.net --- I also experience this with PDF-Xchange Editor Plus version 9.3 on openSUSE Leap 15.3 KDE Plasma Version: 5.18.6 KDE Frameworks Version: 5.76.0 Qt Version: 5.12.7 Kernel Version: 5.3.18-150300.59.68-default. It's sufficiently annoying that I fall back to an older version of the PDF-Xchange program which doesn't exhibit this characteristic. A trial version of PDF-Xchange can be downloaded from https://www.tracker-software.com/product/downloads in case anyone wants to check for themselves. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #21 from Knecker <l4vebs1mx(a)relay.firefox.com> --- (In reply to fhb33435w from comment #20)
I also experience this with PDF-Xchange Editor Plus version 9.3 on openSUSE Leap 15.3 KDE Plasma Version: 5.18.6 KDE Frameworks Version: 5.76.0 Qt Version: 5.12.7 Kernel Version: 5.3.18-150300.59.68-default. It's sufficiently annoying that I fall back to an older version of the PDF-Xchange program which doesn't exhibit this characteristic. A trial version of PDF-Xchange can be downloaded from https://www.tracker-software.com/product/downloads in case anyone wants to check for themselves.
I found a workaround for this problem: Set the Windows Version to 10 in $ winecfg. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #22 from fhb33435w(a)postedmail.net --- (In reply to Knecker from comment #21)
(In reply to fhb33435w from comment #20)
I also experience this with PDF-Xchange Editor Plus version 9.3 on openSUSE Leap 15.3 KDE Plasma Version: 5.18.6 KDE Frameworks Version: 5.76.0 Qt Version: 5.12.7 Kernel Version: 5.3.18-150300.59.68-default. It's sufficiently annoying that I fall back to an older version of the PDF-Xchange program which doesn't exhibit this characteristic. A trial version of PDF-Xchange can be downloaded from https://www.tracker-software.com/product/downloads in case anyone wants to check for themselves.
I found a workaround for this problem: Set the Windows Version to 10 in $ winecfg.
Thanks very much! I would have never thought to try that. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 jubilantjerry(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jubilantjerry(a)gmail.com --- Comment #23 from jubilantjerry(a)gmail.com --- Drop shadow is still appearing for me, on top of all windows. I run Wine 7.16 Staging, and see the issue for WeChat, DingDing, and their installers. winecfg Windows 10 workaround does not work for me. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #24 from jubilantjerry(a)gmail.com --- I've found a workaround in my instance of this bug. If I use an Ubuntu keyboard shortcut to minimize the application window showing the drop shadow problem, then the drop shadow no longer lingers on top of all windows even after the main window is restored. After starting the application fresh, if I use the minimize button that comes with the application window, the drop shadow is gone. But the drop shadow will come back when the main window is restored. If I use the keyboard shortcut, then the drop shadow never comes back, regardless of how I restore / minimize / resize the same window afterward. New windows created by the same application may still show the drop shadow. Not all windows respond to the Ubuntu shortcut, which is kind of annoying, but having the main window be responsive to that is already a nice improvement. This leaves me with a couple questions: if the drop shadow is behaving like a window, why doesn't it appear as a separate entry in the dock like other cases when an application has multiple windows, and why does the keyboard shortcut handle this differently from pressing the minimize button? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Knecker <l4vebs1mx(a)relay.firefox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|l4vebs1mx(a)relay.firefox.com | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |399989567(a)qq.com --- Comment #25 from Jactry Zeng <jactry92(a)gmail.com> --- *** Bug 53771 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #26 from 399989567(a)qq.com --- (In reply to jubilantjerry from comment #24)
I've found a workaround in my instance of this bug. If I use an Ubuntu keyboard shortcut to minimize the application window showing the drop shadow problem, then the drop shadow no longer lingers on top of all windows even after the main window is restored.
After starting the application fresh, if I use the minimize button that comes with the application window, the drop shadow is gone. But the drop shadow will come back when the main window is restored. If I use the keyboard shortcut, then the drop shadow never comes back, regardless of how I restore / minimize / resize the same window afterward. New windows created by the same application may still show the drop shadow. Not all windows respond to the Ubuntu shortcut, which is kind of annoying, but having the main window be responsive to that is already a nice improvement.
This leaves me with a couple questions: if the drop shadow is behaving like a window, why doesn't it appear as a separate entry in the dock like other cases when an application has multiple windows, and why does the keyboard shortcut handle this differently from pressing the minimize button?
I'm sure "the drop shadow" is a window,For DingTalk's drop shadow ——————————————— Possible useful information for Window S(which is used to modify the previous window)： APPS：DingTalk APP_Download_URL:https://dtapp-pub.dingtalk.com/dingtalk-desktop/win_downloader/dingtalk_down... [ You can reproduce the problem without an account ] - Function calls for drawing windows：CreateWindowExW -> WIN_CreateWindowEx - Windows className:DuiShadowWnd - style: WS_POPUP WS_CLIPSIBLINGS style=84000000 - exstyle: WS_EX_TRANSPARENT WS_EX_TOOLWINDOW WS_EX_LAYERED WS_EX_NOACTIVATE ex=080800a0 ——————————————— so I think it's a window -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #27 from jubilantjerry(a)gmail.com --- (In reply to 399989567 from comment #26) I also saw your post on Bug 53771, good investigative work. I think because of these options, the transparent window doesn't show up on the dock / taskbar? WS_EX_TRANSPARENT WS_EX_TOOLWINDOW WS_EX_LAYERED WS_EX_NOACTIVATE My guess is that the Ubuntu shortcut minimizes all windows attached to the main one, including tool windows, whereas the minimize button is actually just a normal button on the window that doesn't minimize the transparent part. Perhaps the restore logic doesn't explicitly restore the transparent window because Wechat / QQ / DingTalk expects the transparent window to always be present. Sven, does your tool show whether windows are truly minimized or not? If so could you check if the transparent window is still there if you minimize DingTalk on Windows? I noticed that Ubuntu itself also draws drop shadows on windows that have focus. But I verified that the shadow that lingers after minimization the app's custom shadow, not Ubuntu's. For one, Ubuntu only draws the shadow on windows that have focus. Secondly, the shadow looks different. See my attachments: shadows_1 shows the Ubuntu drop shadow around a Firefox window that has focus vs. a lingering buggy shadow from DingTalk vs. a shadow from a non-minimized Wechat window that is not in focus. The Firefox shadow is lighter. shadows_2 shows what I see if I give focus to the Wechat window. The Wechat shadow is darker than even the buggy shadow from DingTalk, and there's no shadow around the Firefox window. This means the Wechat window in focus has both the Ubuntu shadow and the transparent window's shadow. These results mean that the invisible shadow window is not minimized and still rendering the shadow, as expected. What I don't know is what is supposed to happen on real Windows - does the invisible window get minimized too, or does the invisible window stay non-minimized and simply stops rendering the shadow? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #28 from jubilantjerry(a)gmail.com --- Created attachment 73256 --> https://bugs.winehq.org/attachment.cgi?id=73256 Comparison of drop shadows of 3 windows -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 jubilantjerry(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #73256|Comparison of drop shadows |shadows_1 description|of 3 windows | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 jubilantjerry(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #73256|shadows_1 |shadows2 description| | Attachment #73256|shadows1.png |shadows2.png filename| | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #29 from jubilantjerry(a)gmail.com --- Created attachment 73257 --> https://bugs.winehq.org/attachment.cgi?id=73257 shadows1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 jubilantjerry(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #73257|shadows2.png |shadows1.png filename| | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #30 from 399989567(a)qq.com --- (In reply to jubilantjerry from comment #27)
My guess is that the Ubuntu shortcut minimizes all windows attached to the main one, including tool windows, whereas the minimize button is actually just a normal button on the window that doesn't minimize the transparent part. Perhaps the restore logic doesn't explicitly restore the transparent window because Wechat / QQ / DingTalk expects the transparent window to always be present.
The system I use is Debian+X11, in wine7.18, in fact when I click the shrink button in the upper right corner of the window, the transparent window will shrink synchronously.
Sven, does your tool show whether windows are truly minimized or not? If so could you check if the transparent window is still there if you minimize DingTalk on Windows?
I think the tool can't do this. The tool is WinSpy.exe you can download on URL:http://www.catch22.net/assets/files/software/WinSpy17.zip -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #31 from Zeb Figura <z.figura12(a)gmail.com> --- *** Bug 53772 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #32 from 399989567(a)qq.com --- (In reply to Zeb Figura from comment #31)
*** Bug 53772 has been marked as a duplicate of this bug. ***
(In reply to jubilantjerry from comment #27)
(In reply to 399989567 from comment #26)
I also saw your post on Bug 53771, good investigative work.
I think because of these options, the transparent window doesn't show up on the dock / taskbar? WS_EX_TRANSPARENT WS_EX_TOOLWINDOW WS_EX_LAYERED WS_EX_NOACTIVATE
My guess is that the Ubuntu shortcut minimizes all windows attached to the main one, including tool windows, whereas the minimize button is actually just a normal button on the window that doesn't minimize the transparent part. Perhaps the restore logic doesn't explicitly restore the transparent window because Wechat / QQ / DingTalk expects the transparent window to always be present.
Sven, does your tool show whether windows are truly minimized or not? If so could you check if the transparent window is still there if you minimize DingTalk on Windows?
I noticed that Ubuntu itself also draws drop shadows on windows that have focus. But I verified that the shadow that lingers after minimization the app's custom shadow, not Ubuntu's. For one, Ubuntu only draws the shadow on windows that have focus. Secondly, the shadow looks different. See my attachments:
shadows_1 shows the Ubuntu drop shadow around a Firefox window that has focus vs. a lingering buggy shadow from DingTalk vs. a shadow from a non-minimized Wechat window that is not in focus. The Firefox shadow is lighter.
shadows_2 shows what I see if I give focus to the Wechat window. The Wechat shadow is darker than even the buggy shadow from DingTalk, and there's no shadow around the Firefox window. This means the Wechat window in focus has both the Ubuntu shadow and the transparent window's shadow.
These results mean that the invisible shadow window is not minimized and still rendering the shadow, as expected. What I don't know is what is supposed to happen on real Windows - does the invisible window get minimized too, or does the invisible window stay non-minimized and simply stops rendering the shadow?
I found that the reason for the problem is that the window is not added to the window manager, do you know which developer should discuss this problem with? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #33 from 399989567(a)qq.com --- (In reply to Zeb Figura from comment #31)
*** Bug 53772 has been marked as a duplicate of this bug. ***
I would like to ask what is the reason for judging whether a window is added to the window manager in wine. For example, in the is_window_manger function of winex11.drv, I see that the child window in wine does not need to be added to the window manager, and the full-screen window needs to be added to the window manager. ==================== I would like to ask what is the basis for judging whether a window is added to the window manager? I'm not asking the code logic for the judging in wine, I'm asking why the code be coding like that? If we judging a window need to be add to the window manager,What is the basis we follow？ such as : We know that the child window is managed by its parent window, so there is no need to join the window management. ==================== Because I think a visible POPUP window (WS_VISIBLE) in the screen should be added to the window pipe, but I want to know "the basis for judging whether a window is added to the window pipe", and then judge whether my logic is correct. If my logic is correct then this bug will be fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #34 from 399989567(a)qq.com --- (In reply to 399989567 from comment #33)
(In reply to Zeb Figura from comment #31)
*** Bug 53772 has been marked as a duplicate of this bug. ***
I would like to ask what is the reason for judging whether a window is added to the window manager in wine. For example, in the is_window_manger function of winex11.drv, I see that the child window in wine does not need to be added to the window manager, and the full-screen window needs to be added to the window manager.
====================
I would like to ask what is the basis for judging whether a window is added to the window manager? I'm not asking the code logic for the judging in wine, I'm asking why the code be coding like that? If we judging a window need to be add to the window manager,What is the basis we follow？
such as : We know that the child window is managed by its parent window, so there is no need to join the window management.
====================
Because I think a visible POPUP window (WS_VISIBLE) in the screen should be added to the window pipe, but I want to know "the basis for judging whether a window is added to the window pipe", and then judge whether my logic is correct.
If my logic is correct then this bug will be fixed.
I refuted myself, adding the shadow window to the window manager can indeed solve the problem, and the shadow window will not be displayed on the top layer, but such modification will cause new problems, so there should be a corresponding reason that wine did not do this in the design. consideration (although I still don't know what kind of consideration) I will still be here for getting the basis for judging whether a window is added to the window manager. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Peet <pisit.jee(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pisit.jee(a)gmail.com --- Comment #35 from Peet <pisit.jee(a)gmail.com> --- In my case i go to wine config > graphics > then uncheck "Allow the window manager to decorate the windows" and it work for me. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Clocks <doomsdayrs(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |doomsdayrs(a)gmail.com --- Comment #36 from Clocks <doomsdayrs(a)gmail.com> --- With the Wayland driver enabled, this issue leads to WeChat and similar applications being completely unusable. With Wine 8.17 I was able to cycle the wine theme via winecfg between light and dark to cause the shadow window to become visible. As of Wine 8.19 I am no longer able to do the above bypass. If DingTalk, WeChat, and other shadow-windowed applications are run via wayland, all UI elements are completely inaccessible. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winex11.drv --- Comment #37 from Jactry Zeng <jactry92(a)gmail.com> --- (In reply to Clocks from comment #36)
If DingTalk, WeChat, and other shadow-windowed applications are run via wayland, all UI elements are completely inaccessible.
This sounds like an issue of the wayland driver. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 --- Comment #38 from Clocks <doomsdayrs(a)gmail.com> --- (In reply to Jactry Zeng from comment #37)
(In reply to Clocks from comment #36)
If DingTalk, WeChat, and other shadow-windowed applications are run via wayland, all UI elements are completely inaccessible.
This sounds like an issue of the wayland driver.
Hardly, this specifically is an application issue. These programs expect to be able to shadow a window on Windows. X11 had support for this use case. Wayland does not support this use case. It is quite impossible for Wayland to ever support this use case, and it likely never will be supported. Thus the only options are. 1. The developers of the application fix the issue by allowing the shadow to be disabled. 2. Wine to explicitly deny the application the ability to do a shadow. We have control over the second option. Thus should advocate for the second option. Which is known to solve the issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 yan12125 <pq2sx44teeigl7za(a)chyen.cc> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pq2sx44teeigl7za(a)chyen.cc -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=34631 Real Name <thismailboxforspam(a)proton.me> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thismailboxforspam(a)proton.m | |e --- Comment #39 from Real Name <thismailboxforspam(a)proton.me> --- (In reply to Clocks from comment #38)
(In reply to Clocks from comment #36)
(In reply to Jactry Zeng from comment #37) 2. Wine to explicitly deny the application the ability to do a shadow.
We have control over the second option. Thus should advocate for the second option. Which is known to solve the issue.
How ability to do a shadow may be disabled? I didn't find any information in the Internet -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla