On 13/07/2020 01:21, Rafał Mużyło wrote:
On Sun, Jul 12, 2020 at 07:39:18PM +0200, Stefan Dösinger wrote:
Am 11.07.2020 um 01:11 schrieb Rafał Mużyło galtgendo@o2.pl:
Right now, wine handles desktop switches by an artificial sequence of minimize/restore. It's not the minimize part that's the problem, it's restore.
After re-reading the mails there are still some things that are not quite clear to me...
Do things work as intended when you normally minimize and restore the window, or does that already lead to unexpected behavior?
Even if 'just' the restore is a problem (e.g. because an application does not expect to be restored without gaining focus at the same time) the answer might still be to not minimize the window in the first place, so it doesn't need to be restored.
I always thought it is the Linux desktop manager that does the minimizing / restoring on desktop switching. I never checked though. The other potential pain is that different window managers might have different behavior.
Argh...
So, let's start with a link: https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html - Section Virtul Desktops.
Obviously, I'm going with the second option there.
Now, I've got focus-follows-mouse and desktop switch bound to mouse scroll - not really important, just for context.
So, let's say I've got a couple windows on one of the desktops, one of them a wine window of an app that pauses upon losing focus. Now, let's say I switch to another window on that desktop, so that the app pauses.
For now, everything is fine.
Now, I switch to a different desktop, then switch back.
The way wine implements things right now, the app gets unpaused, even if the wm didn't give that wine window focus.
Now, preventing that part would just involve adding a check for _NET_WM_STATE_HIDDEN in the part that does minimizing, that would skip it, yet then another problem arizes: can_activate_window statics in user32 and winex11.drv.
Basically, skipping minimization makes wine consider those windows as valid targets for input despite them being currently invisible.
Currently only sane way I could find to deal with it was by using WS_DISABLED.
As it needs to work with user32 too, simple solutions, limited to just winex11.drv, are out. Which is a pity, cause while it would involve a bit work to make sure no unexpected side-effects would happen, 'mapped' field of window data could be just reused - currently it seems to go out of use as soon as the window is shown the first time.
Again, sounds like implementing DWMWA_CLOAKED is what you want. Especially because Windows also does it for a reason. Current Wine functionality is obviously not "correct" since it's not implemented, you shouldn't try to workaround it.
can_activate_window can then be improved to check for DWMWA_CLOAKED just like it does for WS_VISIBLE and your problem is solved.
Using WS_DISABLED, in contrast, is just a hack to workaround Wine's current functionality. Please read the blog post Henri linked again to understand why all these things can have side-effects to *other* applications.