Sometimes can't switch to workspace.

[kyx0r]

There is an issue, and I think this started happening after the last batch of commits where switching to some workspace does not work at all.

For example you press alt+3 and nothing happens. It depends on what windows I have on that workspace. I think my windows become unmanaged after I switch workspace and then do some more window switching on the other one. But I don't get why it won't even switch the workspace at all.

[kyx0r]

I think this commit has a defect:
418d211

[kyx0r]

The bug is not consistent, I think its a race condition. What helps recreate is closing and opening windows on the workspace 1, after switching from workspace 3.

[kyx0r]

I have reverted that commit for now. I think there is some kind of window focus issue preventing it from working. And it somehow also depends on the types of windows I have on that workspace.

[kyx0r]

Hmm. that did not help. I was wrong. Weird it might be related to going from tall to fullscreen... Need more testing

[kyx0r]

14:29:47.441 WorkspaceList [INFO] Retiling... D=1 WS=1 T=3 L=Tall
14:29:47.441 WorkspaceList [INFO] ExtendedFrameBounds(6095956) are { bottom = 7, left = 7, right = 7, top = 0 }
14:29:47.441 WorkspaceList [INFO] ExtendedFrameBounds(7669606) are { bottom = 7, left = 7, right = 7, top = 0 }
14:29:47.442 WorkspaceList [INFO] ExtendedFrameBounds(131826) are { bottom = 7, left = 7, right = 7, top = 0 }
14:29:47.950 WMEvents [TRACE] EV_WINDOW_DESTROYED: W=3671082
14:29:47.950 WMEvents [TRACE] EV_WINDOW_DESTROYED: W=15599260
14:29:48.343 WMEvents [TRACE] EV_WINDOW_HIDDEN: W=21759042
14:29:48.343 WMEvents [TRACE] EV_WINDOW_DESTROYED: W=21759042
14:29:49.151 WMEvents [DEBUG] WM_REQUEST: { type = "focus-workspace", workspace = 3 }
14:29:53.575 WMEvents [DEBUG] WM_REQUEST: { type = "focus-workspace", workspace = 3 }
14:29:57.263 WMEvents [DEBUG] WM_REQUEST: { type = "focus-workspace", workspace = 3 }
14:29:57.799 WMEvents [DEBUG] WM_REQUEST: { type = "focus-workspace", workspace = 3 }
14:29:58.199 WMEvents [DEBUG] WM_REQUEST: { type = "focus-workspace", workspace = 3 }
14:29:58.447 WMEvents [DEBUG] WM_REQUEST: { type = "focus-workspace", workspace = 3 }
14:29:58.647 WMEvents [DEBUG] WM_REQUEST: { type = "focus-workspace", workspace = 3 }
14:29:58.823 WMEvents [DEBUG] WM_REQUEST: { type = "focus-workspace", workspace = 3 }
14:29:59.006 WMEvents [DEBUG] WM_REQUEST: { type = "focus-workspace", workspace = 3 }
14:29:59.174 WMEvents [DEBUG] WM_REQUEST: { type = "focus-workspace", workspace = 3 }
14:30:05.891 WMEvents [TRACE] EV_WINDOW_DESTROYED: W=18481946
14:30:11.686 WMEvents [DEBUG] WM_REQUEST: { type = "focus-workspace", workspace = 3 }

Nothing useful in the logs. You can see trying to switch to 3 many times and nothing happening.

[kyx0r]

Tracking this, I think its because you changed configuration to focusWorkspaceByWindow: true, Seems buggy with the kind of windows that I have on that workspace?

[imawizard]

Yes, the debug messages and the changelog are still lacking, sorry.

Were you using the latest commit with the buggy behavior occurring and what does your config look like?

I changed it to focusWorkspaceByWindow: true because I added remembering the workspace's recently used monitor, making the focus after switching more predictable than using the built-in focus-last-window with focusWorkspaceByWindow: false (when it's working :)

When it's true then WinActivate(target-workspace.ActiveWindow) is used for switching the workspace which only works if the specified window isn't already the active one.

For example, after sending a workspace 1's last window to workspace 2 with followWindowToWorkspace: false, the sent window still had focus prior to cd3c214 which means that WinActivate wouldn't change to workspace 2, even though the currently active workspace was still 1.

[kyx0r]

Yes, the debug messages and the changelog are still lacking, sorry.

Were you using the latest commit with the buggy behavior occurring and what does your config look like?

My config is pretty simple, just few misc changes you can see here:
https://github.com/kyx0r/klec/blob/master/dotfiles/miguru.patch

Yes, this is for the last commit.

Actually I was looking for ahk window manager so that I could just write additional
macros for my needs and have it all in one. [MiguruWM] is definitely the best ahk WM I found so thanks for that!

I changed it to focusWorkspaceByWindow: true because I added remembering the workspace's recently used monitor, making the focus after switching more predictable than using the built-in focus-last-window with focusWorkspaceByWindow: false (when it's working :)

That, I don't really know. I only use 1 monitor. So my use case is the most simple. It's probably a good change, I just don't have any experience of how MiguruWM works when there are many monitors.

When it's true then WinActivate(target-workspace.ActiveWindow) is used for switching the workspace which only works if the specified window isn't already the active one.

For example, after sending a workspace 1's last window to workspace 2 with followWindowToWorkspace: false, the sent window still had focus prior to cd3c214 which means that WinActivate wouldn't change to workspace 2, even though the currently active workspace was still 1.

I see. Changing focusWorkspaceByWindow to false has fixed my issue. I don't think much of anything is needed to be fixed. Maybe just document the focusWorkspaceByWindow flag. Unless you have any other ideas.

[imawizard]

I'm glad that overall it seems to be working for you. Also I'll update Configuration#focusworkspacebywindow and try to add more information.

Could you maybe help me reproduce the bug by giving some more details like:

• How many windows do each of the two workspaces you're switching between has?
• Can you reproduce it with any windows or is it specific to tiled/floating/unmanaged/a specific application's windows?
• What's the order of actions, considering opening, closing, focussing and sending windows and switching workspaces?

[kyx0r]

I'm glad that overall it seems to be working for you. Also I'll update Configuration#focusworkspacebywindow and try to add more information.

Could you maybe help me reproduce the bug by giving some more details like:

• How many windows do each of the two workspaces you're switching between has?

I have unreal 4 game on workspace 3. So just 1 window. Workspace 1 has 2 or more windows, chromium and mintty(s)

• Can you reproduce it with any windows or is it specific to tiled/floating/unmanaged/a specific application's windows?

I think its specific to the game, because it probably does its own shenanigans with window focus. Probably some bug in the game too, because sometimes the game itself kinda loses window focus and the mouse can unhide the taskbar.

• What's the order of actions, considering opening, closing, focussing and sending windows and switching workspaces?

Its kinda random, but I guess the most reliable was going workspace 3 then back to 1, change from tiled to fullscreen on workspace 1, open new mintty window on workspace 1 and then try switching to workspace 3. It gets stuck from there.
Note that switching to any other workspace, like 2, 4-9 works fine. Just 3 breaks.