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.