Re: [PATCH] winex11.drv: Let the Window Manager handle the off-screen window if it's managed.

[Gabriel Ivăncescu]

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.

[PATCH] winex11.drv: Let the Window Manager handle the off-screen window if it's managed.

[Alexandre Julliard]

Gabriel Ivăncescu  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.

[PATCH] winex11.drv: Let the Window Manager handle the off-screen window if it's managed.

[Gabriel Ivăncescu]

On 15/10/2020 16:09, Alexandre Julliard wrote:
> Gabriel Ivăncescu  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

[PATCH] winex11.drv: Let the Window Manager handle the off-screen window if it's managed.

[Gabriel Ivăncescu]

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