Re: [PATCH] winex11.drv: Let the Window Manager handle the off-screen window if it's managed.
On 14/10/2020 23:37, Marvin wrote:
Thank you for your contribution to Wine!
This is an automated notification to let you know that your patch has been reviewed and its status set to "Rejected".
This means that the patch has been rejected by a reviewer. You should have received a mail explaining why it was rejected. You need to fix the issue and resend the patch, or if you are convinced that your patch is good as is, you should reply to the rejection message with your counterarguments.
If you do not understand the reason for this status, disagree with our assessment, or are simply not sure how to proceed next, please ask for clarification by replying to this email.
Hi,
Why was this rejected? To me, as it stands, it makes no sense to try to unmap the window if it's offscreen when it is managed; we're overriding its job.
Some WMs implement their own virtual desktops/workspaces and "snap" and "shift" the windows when they're offscreen (e.g. if you move the window to the left, it snaps to the left workspace and shifts up to the right when you switch to it). This completely ignores that and hides them when they would *not* be hidden by the WM.
Gabriel Ivăncescu gabrielopcode@gmail.com writes:
On 14/10/2020 23:37, Marvin wrote:
Thank you for your contribution to Wine!
This is an automated notification to let you know that your patch has been reviewed and its status set to "Rejected".
This means that the patch has been rejected by a reviewer. You should have received a mail explaining why it was rejected. You need to fix the issue and resend the patch, or if you are convinced that your patch is good as is, you should reply to the rejection message with your counterarguments.
If you do not understand the reason for this status, disagree with our assessment, or are simply not sure how to proceed next, please ask for clarification by replying to this email.
Hi,
Why was this rejected? To me, as it stands, it makes no sense to try to unmap the window if it's offscreen when it is managed; we're overriding its job.
Some WMs implement their own virtual desktops/workspaces and "snap" and "shift" the windows when they're offscreen (e.g. if you move the window to the left, it snaps to the left workspace and shifts up to the right when you switch to it). This completely ignores that and hides them when they would *not* be hidden by the WM.
Yes, that's the point. Some apps move windows offscreen on purpose and expect them to be hidden, so the WM keeping them on screen is a bug.
On 15/10/2020 16:09, Alexandre Julliard wrote:
Gabriel Ivăncescu gabrielopcode@gmail.com writes:
On 14/10/2020 23:37, Marvin wrote:
Thank you for your contribution to Wine!
This is an automated notification to let you know that your patch has been reviewed and its status set to "Rejected".
This means that the patch has been rejected by a reviewer. You should have received a mail explaining why it was rejected. You need to fix the issue and resend the patch, or if you are convinced that your patch is good as is, you should reply to the rejection message with your counterarguments.
If you do not understand the reason for this status, disagree with our assessment, or are simply not sure how to proceed next, please ask for clarification by replying to this email.
Hi,
Why was this rejected? To me, as it stands, it makes no sense to try to unmap the window if it's offscreen when it is managed; we're overriding its job.
Some WMs implement their own virtual desktops/workspaces and "snap" and "shift" the windows when they're offscreen (e.g. if you move the window to the left, it snaps to the left workspace and shifts up to the right when you switch to it). This completely ignores that and hides them when they would *not* be hidden by the WM.
Yes, that's the point. Some apps move windows offscreen on purpose and expect them to be hidden, so the WM keeping them on screen is a bug.
I've been thinking about this a bit. Unfortunately I can't find a way around this easily. If a WM keeps it on screen, and we don't want that (because apps depend on it not doing so), this breaks WMs that support off-screen coordinates due to things like Virtual Desktops/Workspaces. (the window becomes hidden, but it's not in any workspace, it's simply hidden; the WM isn't informed of it).
Is there a way (at least wrt to winex11.drv) to detect if the WM refuses to move the window? Perhaps in the ConfigureNotify? I don't know if unmapping it there would solve the problem, though.
BTW, I wonder how do those apps work on Windows 10 with multiple virtual desktops? It might provide some clues. Do you remember an example of such an app?
Thanks, Gabriel
What do you think about a registry setting to control the behavior of unmapping offscreen windows? Since this is a WM quirk, it's suitable for that. I can't find a solution otherwise; the app handles WM_MOUSEMOVE and does its own logic to the cursor depending on what it *thinks* the window position is at that time (I believe it uses a timer).
Since the coordinates are relative to the window, when the window is moved by the WM to fit on screen, the cursor will be way off, so Winamp thinks the mouse moved too much and it will move it offscreen really quickly.
Anyway, not unmapping it when offscreen fixes it, but since it's working around a quirk, it should be a non-default registry setting.
Does that sound like a good idea or a waste of time?
Thanks, Gabriel
-
Alexandre Julliard -
Gabriel Ivăncescu