[RFC] Trying to fix desktop switches, cont.
So, after the previous post, I sat down and once again did some thinking/tinkering. Obviously, the previous patch couldn't work, at least not in the restoring part. This one seems to work (for now), though I've only did some very basic testing. It doesn't seem to be a way to add private data to a window, that would both be only accessible by wine and integrated with standard winapi calls. Correct me, if that's wrong. While WS_HIDDEN would seem better fitting, AFAICT it removes the window from event queues, so I went with WS_DISABLED. This time through standard functions.
Hi Rafał, On 08/07/2020 22:36, Rafał Mużyło wrote:
So, after the previous post, I sat down and once again did some thinking/tinkering.
Obviously, the previous patch couldn't work, at least not in the restoring part.
This one seems to work (for now), though I've only did some very basic testing.
It doesn't seem to be a way to add private data to a window, that would both be only accessible by wine and integrated with standard winapi calls. Correct me, if that's wrong.
While WS_HIDDEN would seem better fitting, AFAICT it removes the window from event queues, so I went with WS_DISABLED. This time through standard functions.
AFAIK, Windows 10 supports multiple desktops / workspaces. Did you try to see what happens in Windows 10 when you switch desktops?
On Thu, 9 Jul 2020 at 16:12, Gabriel Ivăncescu <gabrielopcode(a)gmail.com> wrote:
On 08/07/2020 22:36, Rafał Mużyło wrote:
So, after the previous post, I sat down and once again did some thinking/tinkering.
Obviously, the previous patch couldn't work, at least not in the restoring part.
This one seems to work (for now), though I've only did some very basic testing.
It doesn't seem to be a way to add private data to a window, that would both be only accessible by wine and integrated with standard winapi calls. Correct me, if that's wrong.
While WS_HIDDEN would seem better fitting, AFAICT it removes the window from event queues, so I went with WS_DISABLED. This time through standard functions.
AFAIK, Windows 10 supports multiple desktops / workspaces. Did you try to see what happens in Windows 10 when you switch desktops?
Potentially relevant: https://devblogs.microsoft.com/oldnewthing/20200302-00/?p=103507
On Thu, Jul 09, 2020 at 05:31:34PM +0430, Henri Verbeet wrote:
On Thu, 9 Jul 2020 at 16:12, Gabriel Ivăncescu <gabrielopcode(a)gmail.com> wrote:
On 08/07/2020 22:36, Rafał Mużyło wrote:
AFAIK, Windows 10 supports multiple desktops / workspaces. Did you try to see what happens in Windows 10 when you switch desktops?
Potentially relevant: https://devblogs.microsoft.com/oldnewthing/20200302-00/?p=103507
Kind of interesting, yet likely orthogonal, as all the time I was (as explicitly noted in the previous post) talking about *X11* virtual desktops. If wine already did implement DWMWA_CLOAKED, then yes, *perhaps* that would be a valid way of solving this problem, but even then I doubt it would be 1:1 solution.
On Thu, 9 Jul 2020 at 20:51, Rafał Mużyło <galtgendo(a)o2.pl> wrote:
On Thu, Jul 09, 2020 at 05:31:34PM +0430, Henri Verbeet wrote:
On Thu, 9 Jul 2020 at 16:12, Gabriel Ivăncescu <gabrielopcode(a)gmail.com> wrote:
On 08/07/2020 22:36, Rafał Mużyło wrote:
AFAIK, Windows 10 supports multiple desktops / workspaces. Did you try to see what happens in Windows 10 when you switch desktops?
Potentially relevant: https://devblogs.microsoft.com/oldnewthing/20200302-00/?p=103507
Kind of interesting, yet likely orthogonal, as all the time I was (as explicitly noted in the previous post) talking about *X11* virtual desktops.
It was clear that you were talking about X11 virtual desktops, yes. I think ideally we'd map between the two concepts somehow, but the reason I thought that post was potentially relevant was that it describes some of the considerations behind the Windows 10 implementation of virtual desktops.
On 09/07/2020 19:41, Henri Verbeet wrote:
On Thu, 9 Jul 2020 at 20:51, Rafał Mużyło <galtgendo(a)o2.pl> wrote:
On Thu, Jul 09, 2020 at 05:31:34PM +0430, Henri Verbeet wrote:
On Thu, 9 Jul 2020 at 16:12, Gabriel Ivăncescu <gabrielopcode(a)gmail.com> wrote:
On 08/07/2020 22:36, Rafał Mużyło wrote:
AFAIK, Windows 10 supports multiple desktops / workspaces. Did you try to see what happens in Windows 10 when you switch desktops?
Potentially relevant: https://devblogs.microsoft.com/oldnewthing/20200302-00/?p=103507
Kind of interesting, yet likely orthogonal, as all the time I was (as explicitly noted in the previous post) talking about *X11* virtual desktops.
It was clear that you were talking about X11 virtual desktops, yes. I think ideally we'd map between the two concepts somehow, but the reason I thought that post was potentially relevant was that it describes some of the considerations behind the Windows 10 implementation of virtual desktops.
In my opinion, implementing DWMWA_CLOAKED and then implementing this feature with DWMWA_CLOAKED sounds like the proper solution here. The link Henri posted reveals many reasons why, too. Rafał, you said that your application pauses when it is minimized by Wine (which is what it does when you switch X11 virtual desktops now), and "disabling" it works. But it works for that particular app. Other applications might have undesired behavior when disabled, especially because it's not an operation a user can typically do. That's why it's not a good idea (unless Windows also did it, but that's not the case here).
On Fri, Jul 10, 2020 at 05:47:32PM +0300, Gabriel Ivăncescu wrote:
On 09/07/2020 19:41, Henri Verbeet wrote:
On Thu, 9 Jul 2020 at 20:51, Rafał Mużyło <galtgendo(a)o2.pl> wrote:
On Thu, Jul 09, 2020 at 05:31:34PM +0430, Henri Verbeet wrote:
On Thu, 9 Jul 2020 at 16:12, Gabriel Ivăncescu <gabrielopcode(a)gmail.com> wrote:
On 08/07/2020 22:36, Rafał Mużyło wrote:
AFAIK, Windows 10 supports multiple desktops / workspaces. Did you try to see what happens in Windows 10 when you switch desktops?
Potentially relevant: https://devblogs.microsoft.com/oldnewthing/20200302-00/?p=103507
Kind of interesting, yet likely orthogonal, as all the time I was (as explicitly noted in the previous post) talking about *X11* virtual desktops.
It was clear that you were talking about X11 virtual desktops, yes. I think ideally we'd map between the two concepts somehow, but the reason I thought that post was potentially relevant was that it describes some of the considerations behind the Windows 10 implementation of virtual desktops.
In my opinion, implementing DWMWA_CLOAKED and then implementing this feature with DWMWA_CLOAKED sounds like the proper solution here. The link Henri posted reveals many reasons why, too.
Rafał, you said that your application pauses when it is minimized by Wine (which is what it does when you switch X11 virtual desktops now), and "disabling" it works. But it works for that particular app.
Other applications might have undesired behavior when disabled, especially because it's not an operation a user can typically do. That's why it's not a good idea (unless Windows also did it, but that's not the case here).
Once again, it would seem someone didn't read the first post. 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. Now that I think about it, it might just be that 'SetActiveWindow(hwnd)' call... I mean, the problem is that upon getting back to the desktop with the window, the window shouldn't be automatically be given focus if the wm doesn't do it. In the patch I'm skipping minimize step to avoid restoration, but that makes the windows treated by both 'can_activate_window' statics as valid targets for events while being invisible. I'm just using WS_DISABLED to prevent that. ...if it's actually just that SetActiveWindow that's the problem, a cleaner solution would be possible, but I'm not sure how SC_RESTORE works...
Am 11.07.2020 um 01:11 schrieb Rafał Mużyło <galtgendo(a)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.
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(a)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.
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(a)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.
participants (4)
-
Gabriel Ivăncescu -
Henri Verbeet -
Rafał Mużyło -
Stefan Dösinger