http://bugs.winehq.org/show_bug.cgi?id=15346 --- Comment #44 from Gabriel Ivăncescu <gabrielopcode@gmail.com> --- (In reply to Giacomo Orlandi from comment #43)
The staged patchset linked here was removed in the following commit: https://gitlab.winehq.org/wine/wine-staging/-/commit/ 588afb24273742f7855a6b621e72571f445bd641
It looks like the code it was patching was removed upstream in the following commit: https://gitlab.winehq.org/wine/wine/-/commit/ e01656d084c08bce67f4a6997902077baa982278
I'm not sure if the bug has been fixed upstream.
Sadly no, it hasn't been fixed, but the staging patch wasn't very correct to begin with. It has been a while since I tried working on this, but as far as I remember, the problem is that Winamp continuously sets its window position when dragged, e.g. to have the other windows follow along, but also keeps track / updates its window position somewhere internally when it does this. This results in some sort of race condition with the X11 side, where it's moved a lot less (and we update the window positon as such), so Winamp thinks it has been moved way more than it has in its own internal application logic. Therefore it tries to move the window "far" away, outside of the screen. This causes winex11 to unmap it, which actually seems to be correct wrt. to Windows (because apparently some apps depend on this), while this patch delegated it to the WM. Most WMs, however, will not allow a window to go offscreen, effectively disabling this functionality. So the patch wasn't correct and, even though it fixed this problem, it was a semi hack in this regard. I tried to find a correct upstreamable solution, which is to fix the discrepancy between Winamp's internal window tracking logic and winex11, but to no avail, it was pretty hairy as I remember. If anyone wants to take a shot at it, feel free to though. -- 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.