https://bugs.winehq.org/show_bug.cgi?id=43009
Bug ID: 43009 Summary: TIM message manager window covered by an unresponsive window Product: Wine-staging Version: 2.7 Hardware: x86 URL: http://dldir1.qq.com/qqfile/qq/TIM1.1.0/20837/TIM1.1.0 .exe OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: lilydjwg@gmail.com CC: erich.e.hoover@wine-staging.com, fracting@gmail.com, michael@fds-team.de, sebastian@fds-team.de Distribution: ArchLinux
TIM is a cleaner version of QQ, successor of QQ Lite.
download and install it: http://dldir1.qq.com/qqfile/qq/TIM1.1.0/20837/TIM1.1.0.exe
ecb6934f7cea33b1458308495fd965a274c6ba2a TIM1.1.0.exe
winetricks riched20 so you can input your QQ number.
login in, then click your avatar on the left top corner, select "消息管理器".
with wine 2.7 you can use it normally. with wine-staging 2.7 movements and clicks on the window cause nothing. Moving the window using the window manager, you can move away an unresponsive window, underlying it there is a normal window you can operate on. Moving the normal window the unresponsive one moves back to cover it.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #1 from lilydjwg@gmail.com --- Forgot to say, my window manager is awesome 3.5.9.
https://bugs.winehq.org/show_bug.cgi?id=43009
Gijs Vermeulen acescopezz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |acescopezz@gmail.com
--- Comment #2 from Gijs Vermeulen acescopezz@gmail.com --- If you can build wine from source, can you run a test to find the bad patch? See bug 42988 for a way to do this.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #3 from lilydjwg@gmail.com --- (In reply to Gijs Vermeulen from comment #2)
If you can build wine from source, can you run a test to find the bad patch? See bug 42988 for a way to do this.
The command patchinstall.sh fails with:
Applying /home/lilydjwg/src/wine-staging/patches/d3d11-Deferred_Context/0003-d3d11-Initial-implementation-for-deferred-contexts.patch Applying: d3d11: Initial implementation for deferred contexts. error: patch failed: dlls/d3d11/device.c:2260 error: dlls/d3d11/device.c: patch does not apply Patch failed at 0001 d3d11: Initial implementation for deferred contexts.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #4 from Gijs Vermeulen acescopezz@gmail.com --- (In reply to lilydjwg from comment #3)
(In reply to Gijs Vermeulen from comment #2)
If you can build wine from source, can you run a test to find the bad patch? See bug 42988 for a way to do this.
The command patchinstall.sh fails with:
Applying /home/lilydjwg/src/wine-staging/patches/d3d11-Deferred_Context/0003-d3d11- Initial-implementation-for-deferred-contexts.patch Applying: d3d11: Initial implementation for deferred contexts. error: patch failed: dlls/d3d11/device.c:2260 error: dlls/d3d11/device.c: patch does not apply Patch failed at 0001 d3d11: Initial implementation for deferred contexts.
Did you try applying the patches to wine-git or wine 2.7?
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #5 from lilydjwg@gmail.com --- (In reply to Gijs Vermeulen from comment #4)
Did you try applying the patches to wine-git or wine 2.7?
I tried both git master and the wine-2.7 tag. They failed with different patches.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #6 from Michael Müller michael@fds-team.de --- You need to apply the corresponding patches for the Wine version you try to build.
If you want to build Wine Staging 2.7, you need to checkout the 2.7 version of Wine and Wine Staging:
cd wine; git checkout wine-2.7 cd wine-staging; git checkout v2.7
If you want to build the HEAD of Wine Staging, you need to get the related upstream commit:
cd wine-staging; git checkout HEAD cd wine; git checkout $(../wine-staging/patches/patchinstall.sh --upstream-commit)
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #7 from lilydjwg@gmail.com --- I've got it:
a473ddb697c4665c4a8a9e33b4e3e8400665996b is the first bad commit commit a473ddb697c4665c4a8a9e33b4e3e8400665996b Author: Dmitry Timoshkov dmitry@codeweavers.com Date: Tue Nov 25 20:31:58 2014 +0100
user32: Try harder to find a target for mouse messages
:040000 040000 e35a9c01cdfdccb834a3dba603e9d2ba8228c497 bd2f52e0270953d08407d441850a8d11a10a6ef8 M dlls
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #8 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 58168 --> https://bugs.winehq.org/attachment.cgi?id=58168 patch
(In reply to lilydjwg from comment #0)
TIM is a cleaner version of QQ, successor of QQ Lite.
download and install it: http://dldir1.qq.com/qqfile/qq/TIM1.1.0/20837/TIM1.1.0.exe
The application doesn't run here, it crashes in one of its kernel drivers. How do you workaround the crashes? Also, what is the application name that one is supposed to run? is it Program Files/Tencent/TIM/Bin/TIM.exe? Maybe TIMApp.exe? Something else?
Kernel drivers make me very reluctant to install and investigate this thing under either a real Windows or in a VM.
Anyway, does the attached hack help?
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #9 from lilydjwg@gmail.com --- It didn't crash here at the beginning. Later I found it disappeared after I started it without showing any window. When I ran the second time it worked though. I guess it's some timing issue between several executables it contains.
Make sure you kill all the processes after the installation is complete. Maybe it's relevant.
The executable to run is TIM.exe. TIMApp.exe should also work.
Other changes I've made though it's not necessary (at least it doesn't crash): * winetricks sandbox * Windows version set to win10, but xp for TIM.exe (for the default browser) * disable txplatform.exe and qqprotectupd.exe * replace iphlpapi.dll with a native one (for addding buddies window to not freeze) * also I've disabled winemenubuilder.exe
I'll try the patch later.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #10 from lilydjwg@gmail.com --- The patch didn't work. I applied the patch to the HEAD after applying all the staging patches to wine master.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #11 from lilydjwg@gmail.com --- BTW, run TIM.exe in the directory where it resides. It may have problems with other working directory.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #12 from Dmitry Timoshkov dmitry@baikal.ru --- Setting reported version to Windows 10 in winecfg is the key, this prevents the application using its kernel drivers. Next required step is to install riched20 with winetricks in order to be able to type anything.
Unfortunately since I can't read chinese it's impossible for me to create an account and log in to reproduce the real problem. Is it possible to create an account for testing purposes?
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #13 from lilydjwg@gmail.com --- Oh really? I thought I successfully ran it with default Windows version once. Maybe I mistook it.
There was a QQ account here but it doesn't work now. If you're willing you can register one using this English form: https://ssl.zc.qq.com/en/index.html. It may require a phone number, or requiring one when changing passwords.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #14 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #13)
Oh really? I thought I successfully ran it with default Windows version once. Maybe I mistook it.
There was a QQ account here but it doesn't work now. If you're willing you can register one using this English form: https://ssl.zc.qq.com/en/index.html. It may require a phone number, or requiring one when changing passwords.
It requires a phone number for the verification code, that's too much I'm afraid for a testing account.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #15 from lilydjwg@gmail.com --- Oh yeah, nowadays registration for nearly all Chinese websites requires a phone number :-(
Anyway, can you tell me how to debug this?
PS: If I recall correctly this also happened for another program by Tencent (and that one requires a phone number too).
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #16 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #15)
Anyway, can you tell me how to debug this?
First thing to figure out is to get the properties of that unresponsive window (class name, class style, window name, window style/exstyle). Next step is to create the windows tree sorted by z-order the application creates. This task could be done using tools like Spy++ and similar.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #17 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #16)
(In reply to lilydjwg from comment #15)
Anyway, can you tell me how to debug this?
First thing to figure out is to get the properties of that unresponsive window (class name, class style, window name, window style/exstyle). Next step is to create the windows tree sorted by z-order the application creates. This task could be done using tools like Spy++ and similar.
I'm using WinSpy++.
Class is TXGFLayerMask, no/empty caption, style WS_{POPUP,VISIBLE,CLIPSIBLINGS,CLIPCHILDREN}, exstyle WS_EX_TOOLWINDOW, and three are shown in gray: WS_EX_{LEFT,LTRREADING,RIGHTSCROLLBAR}. TIM.exe crashes when I switch WinSpy++ to the "Class" tab.
It has two children and no siblings. Both have class TXGuiFoundation. The parent window is the underlying window but the underlying window doesn't have any children.
When I make it invisible by the dropdown menu provided by WinSpy++, the unresponsive window disappears and the underlying window works normally.
https://bugs.winehq.org/show_bug.cgi?id=43009
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #18 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #17)
Class is TXGFLayerMask, no/empty caption, style WS_{POPUP,VISIBLE,CLIPSIBLINGS,CLIPCHILDREN}, exstyle WS_EX_TOOLWINDOW, and three are shown in gray: WS_EX_{LEFT,LTRREADING,RIGHTSCROLLBAR}. TIM.exe crashes when I switch WinSpy++ to the "Class" tab.
It has two children and no siblings. Both have class TXGuiFoundation. The parent window is the underlying window but the underlying window doesn't have any children.
When I make it invisible by the dropdown menu provided by WinSpy++, the unresponsive window disappears and the underlying window works normally.
Thanks!
Please generate +class,+win,+msg,+event,+tid log (preferably running 'wine winver' in another xterm first to avoid start up noice in the log) and attach it here. Attaching another log with the culprit patch reverted would be also useful.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #19 from lilydjwg@gmail.com --- Created attachment 58176 --> https://bugs.winehq.org/attachment.cgi?id=58176 WINEDEBUG=+class,+win,+msg,+event,+tid with the issue
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #20 from lilydjwg@gmail.com --- Created attachment 58177 --> https://bugs.winehq.org/attachment.cgi?id=58177 WINEDEBUG=+class,+win,+msg,+event,+tid with the commit reverted
Note this one is generated on a different system (on which I bisected the commit) than the previous log (on my work machine with wine-staging from the official Arch repo).
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #21 from Dmitry Timoshkov dmitry@baikal.ru --- Thanks for the logs. I'd need to write a test app to better see how it's supposed to work.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #22 from Dmitry Timoshkov dmitry@baikal.ru --- In short: the unresponsive window in question is a layered window with an assigned color key. I guess that the window surface bitmap is used as a layer mask, and is supposed to be "transparent" both visually and for mouse clicks. winex11.drv calculates the mask shape and instructs the WM about it, so WM sends the button click event to an underlying window. But user32 side is not aware about that masked shape, and currently there is no way to check for it from WINPOS_WindowFromPoint.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #23 from Dmitry Timoshkov dmitry@baikal.ru --- It should be possible to verify my guess by disabling the shaping of layered windows on winex11.drv side. In order to do that create a key "ShapeLayeredWindows"="N" under "X11 Driver" section in the registry. See https://wiki.winehq.org/Useful_Registry_Keys how to do it, it looks like ShapeLayeredWindows setting is not documented there.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #24 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Dmitry Timoshkov from comment #23)
It should be possible to verify my guess by disabling the shaping of layered windows on winex11.drv side. In order to do that create a key "ShapeLayeredWindows"="N" under "X11 Driver" section in the registry. See https://wiki.winehq.org/Useful_Registry_Keys how to do it, it looks like ShapeLayeredWindows setting is not documented there.
The test above should be done with the culprit patch reverted (or using unpatched winehq source). Once the key above is added to the registry the problem with unresponsive window should always present.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #25 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #23)
It should be possible to verify my guess by disabling the shaping of layered windows on winex11.drv side. In order to do that create a key "ShapeLayeredWindows"="N" under "X11 Driver" section in the registry. See https://wiki.winehq.org/Useful_Registry_Keys how to do it, it looks like ShapeLayeredWindows setting is not documented there.
I get strange results.
With this setting, I get a white window that I can't move or close. But I can minimize it, and after I restore the window it behaves normally with all the functionality usable.
I also test the original issue after minimizing and restoring. The unresponsive window is gone after that.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #26 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 58178 --> https://bugs.winehq.org/attachment.cgi?id=58178 patch
Could you please test the attached patch? It was created against staging tree, previous hack should be reverted, make sure that "ShapeLayeredWindows"="Y" is set or that setting is removed from the registry.
The patch adds experimental support for a layered window region.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #27 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #25)
It should be possible to verify my guess by disabling the shaping of layered windows on winex11.drv side. In order to do that create a key "ShapeLayeredWindows"="N" under "X11 Driver" section in the registry. See https://wiki.winehq.org/Useful_Registry_Keys how to do it, it looks like ShapeLayeredWindows setting is not documented there.
I get strange results.
With this setting, I get a white window that I can't move or close. But I can minimize it, and after I restore the window it behaves normally with all the functionality usable.
I also test the original issue after minimizing and restoring. The unresponsive window is gone after that.
Thanks for the testing, the result pretty much confirms my theory.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #28 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #26)
Created attachment 58178 [details] patch
Could you please test the attached patch? It was created against staging tree, previous hack should be reverted, make sure that "ShapeLayeredWindows"="Y" is set or that setting is removed from the registry.
The patch adds experimental support for a layered window region.
Oops, I can't login anymore. The login window shows up with animation! (That animation exists in Windows but I never saw it in Wine.) But then it seems to freeze, and moving mouse over it will hide the mouse cursor. I can close it, and it disappears with animation too.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #29 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #28)
Oops, I can't login anymore. The login window shows up with animation! (That animation exists in Windows but I never saw it in Wine.) But then it seems to freeze, and moving mouse over it will hide the mouse cursor. I can close it, and it disappears with animation too.
I guess that's how the progress looks like sometimes :)
I'll attach a slightly trimmed down version of the patch that reduces new functionality only to point_from_window() on the server side, and leaves visible region calculations intact. Please give it a try.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #30 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 58179 --> https://bugs.winehq.org/attachment.cgi?id=58179 patch2
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #31 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #30)
Created attachment 58179 [details] patch2
The animation is gone, nothing else changes.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #32 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #31)
The animation is gone, nothing else changes.
Please add +server,+relay to the debug flags and generate another log with last patch applied. There is no need to start 'wine winver' in a separate terminal this time beforehand.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #33 from Dmitry Timoshkov dmitry@baikal.ru --- New log is going to be pretty large, please compress it before attaching.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #34 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #33)
New log is going to be pretty large, please compress it before attaching.
The log is huge (1.6G uncompressed), I've uploaded it here: https://transfer.sh/iy1J0/relay.log.xz
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #35 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #34)
The log is huge (1.6G uncompressed), I've uploaded it here: https://transfer.sh/iy1J0/relay.log.xz
Thanks for the log. Unfortunately the log doesn't contain a window with the class "TXGFLayerMask", and there is no any layered window either. Did you try to reproduce the problem while creating the log?
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #36 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #35)
Thanks for the log. Unfortunately the log doesn't contain a window with the class "TXGFLayerMask", and there is no any layered window either. Did you try to reproduce the problem while creating the log?
With last patch I can't login, so there is only one window that I can see: the login window. I thought you were debugging why that window hides my mouse and does not response.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #37 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #36)
Thanks for the log. Unfortunately the log doesn't contain a window with the class "TXGFLayerMask", and there is no any layered window either. Did you try to reproduce the problem while creating the log?
With last patch I can't login, so there is only one window that I can see: the login window. I thought you were debugging why that window hides my mouse and does not response.
Sorry about not being clear enough, looks like I misunderstood your description. I'd like to better see what is going on with the layered window during its lifetime, so I'd need a log with "TXGFLayerMask" window present. Then please generate the log using last debug flags and with plain staging tree (i.e. without testing patches attached to this bug).
I'll keep the log you've created just in case I'll need to investigate the login window bug caused by my experimental patch. Thanks!
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #38 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 58186 --> https://bugs.winehq.org/attachment.cgi?id=58186 patch3
Thanks to your log i think that I've found the problem with my previous version of the patch. Please try this patch.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #39 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #38)
Created attachment 58186 [details] patch3
Thanks to your log i think that I've found the problem with my previous version of the patch. Please try this patch.
With this patch, the original problem is still there. I see no changes compared to the version without the patch.
I'm still uploading the log you asked for now. It's huge (4.4G uncompressed, 137M compressed) and makes wine very slow.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #40 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #39)
(In reply to Dmitry Timoshkov from comment #38)
Created attachment 58186 [details] patch3
Thanks to your log i think that I've found the problem with my previous version of the patch. Please try this patch.
With this patch, the original problem is still there. I see no changes compared to the version without the patch.
Let me clarify things, so unresponsive window (original problem) still exists, but the bug I introduced in patches 1,2 that didn't allow you to login got fixed, right?
I'm still uploading the log you asked for now. It's huge (4.4G uncompressed, 137M compressed) and makes wine very slow.
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #41 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #40)
Let me clarify things, so unresponsive window (original problem) still exists, but the bug I introduced in patches 1,2 that didn't allow you to login got fixed, right?
Yes.
I'm still uploading the log you asked for now. It's huge (4.4G uncompressed, 137M compressed) and makes wine very slow.
Thanks!
Here's the log: https://transfer.sh/ZITef/relay.log.xz (without any patches, only wine-staging)
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #42 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #41)
Let me clarify things, so unresponsive window (original problem) still exists, but the bug I introduced in patches 1,2 that didn't allow you to login got fixed, right?
Yes.
I'm still uploading the log you asked for now. It's huge (4.4G uncompressed, 137M compressed) and makes wine very slow.
Thanks!
Here's the log: https://transfer.sh/ZITef/relay.log.xz (without any patches, only wine-staging)
Hmm, did you test the patch3 then?
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #43 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #42)
Hmm, did you test the patch3 then?
Yes I tested, but without logs. The log completed before I saw patch3. Do you need it also? It'll take some time.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #44 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #43)
Hmm, did you test the patch3 then?
Yes I tested, but without logs. The log completed before I saw patch3. Do you need it also? It'll take some time.
Yes, ideally I'd need the log with patch3 applied to see why it doesn't work. I asked for the log without patches because the patches didn't allow you to login and I needed something to investigate.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #45 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #44)
Yes, ideally I'd need the log with patch3 applied to see why it doesn't work. I asked for the log without patches because the patches didn't allow you to login and I needed something to investigate.
Here's it: https://transfer.sh/ni3Up/relay2.log.xz
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #46 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #45)
Here's it: https://transfer.sh/ni3Up/relay2.log.xz
Thanks for the log. It looks like that there is (an existing) bug in the code that creates region from a bitmap.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #47 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 58202 --> https://bugs.winehq.org/attachment.cgi?id=58202 patch4
Does the attached patch work better?
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #48 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #47)
Created attachment 58202 [details] patch4
Does the attached patch work better?
This one works, thanks!
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #49 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #48)
This one works, thanks!
Great, thanks for testing. Does the animation (that you mentioned earlier) work with this version of the patch?
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #50 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #49)
(In reply to lilydjwg from comment #48)
This one works, thanks!
Great, thanks for testing. Does the animation (that you mentioned earlier) work with this version of the patch?
I can't see the showing up animation, maybe because it's too slow. It shows only part of the window, then the full window.
The disappearing animation and the switching (to settings) animation is fine. And the problem that after the switch, some parts of the window didn't get updated are fixed too :-)
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #51 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #50)
I can't see the showing up animation, maybe because it's too slow. It shows only part of the window, then the full window.
The disappearing animation and the switching (to settings) animation is fine. And the problem that after the switch, some parts of the window didn't get updated are fixed too :-)
Do any of these problems exist in not staging version of wine?
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #52 from lilydjwg@gmail.com --- (In reply to Dmitry Timoshkov from comment #51)
(In reply to lilydjwg from comment #50)
I can't see the showing up animation, maybe because it's too slow. It shows only part of the window, then the full window.
The disappearing animation and the switching (to settings) animation is fine. And the problem that after the switch, some parts of the window didn't get updated are fixed too :-)
Do any of these problems exist in not staging version of wine?
There is no those animations in the normal version of wine. The UI updates problem exists there too.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #53 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to lilydjwg from comment #52)
I can't see the showing up animation, maybe because it's too slow. It shows only part of the window, then the full window.
The disappearing animation and the switching (to settings) animation is fine. And the problem that after the switch, some parts of the window didn't get updated are fixed too :-)
Do any of these problems exist in not staging version of wine?
There is no those animations in the normal version of wine. The UI updates problem exists there too.
Thanks, good to know.
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #54 from lilydjwg@gmail.com --- Hi, Dmitry Timoshkov, I've filed another bug 43085 with TIM. It's also about unresponsible windows, would you like to take a look?
https://bugs.winehq.org/show_bug.cgi?id=43009
--- Comment #55 from Sebastian Lackner sebastian@fds-team.de --- This issue should be fixed with Wine Staging 2.9. Please verify if everything is working as expected and feel free to update the status of this bug report.
https://bugs.winehq.org/show_bug.cgi?id=43009
lilydjwg@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #56 from lilydjwg@gmail.com --- (In reply to Sebastian Lackner from comment #55)
This issue should be fixed with Wine Staging 2.9. Please verify if everything is working as expected and feel free to update the status of this bug report.
I can confirm everything is working as expected. Thanks!
https://bugs.winehq.org/show_bug.cgi?id=43009
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #57 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Fixed Staging 3.14