[Bug] None of my Windows get handled

[Xdavlar]

Describe the bug

Intro

Yesterday I've upgraded glazevm from the earlier C# version to this new version with Zebar and a Rust backend. The installation went fine and the Zebar integration seems to work since I can see the workspace numbers change when using alt+<number>. The problem is that none of my windows get handled so nothing happens when I press for example alt+shift+4 and they don't get tiled either. I've looked at the config and can't find any errors. Things I've tried:

1. Restarting the computer multiple times
2. Using alt+shift+p to see if that was the issue.
   • The workspace numbering on zebar stops updating so I assume the command works.
3. Running glazevm directly on the CLI to see what commands are sent.

CLI Report

When seeing the output log in Powershell it is as the commands that involves manipulating windows are executed. When I for example use alt+left I get Received WM event: FocusChanged { focused_container: Workspace(WorkspaceDto { id: a9c910db-11c8-4b2b-8657-d06127428ace, name: "2", display_name: None, parent_id: Some(5df7aedf-1d36-485a-b6e4-1ef016d31443), children: [], child_focus_order: [], has_focus: true, is_displayed: true, width: 3820, height: 2033, x: 10, y: 45, tiling_direction: Horizontal }) } but if I then press alt+m or alt+shift+left there is no output in the terminal, indicating to me that the command isn't passed along even if Firefox is focused.

Theory

Since none of my windows seems managed by glazevm I'm guessing that none of the "manipulate windows" commands get executed since glaze "thinks" it has no window to act upon. Is there any guess why this happens?

Reproduction

No response

Stack trace or error logs (if applicable)

No response

Version number

3.1.1

[lars-berger]

Is there an errors.log file alongside the config file? Would you mind posting a dump of the logs when you start it from the console?

[Xdavlar]

Here is the log:
errors.log

I can right-click the glazevm in the icon tray use reload-config without issue. Thanks for the QoL by the way :)

[lars-berger]

Here is the log: errors.log

I can right-click the glazevm in the icon tray use reload-config without issue. Thanks for the QoL by the way :)

Nothing interesting there unfortunately. Could you send a dump of the console logs when you run it from a terminal?

[Xdavlar]

Something is iffy either on my computer or somewhere else. This time when I started glazevm to get the log it started to manage some of my active windows but not all, and I can't seem to include the unmanaged either. New windows that are started aren't getting managed either. Here is the log:
startuplog_2024-08-17.txt

[lars-berger]

Something is iffy either on my computer or somewhere else. This time when I started glazevm to get the log it started to manage some of my active windows but not all, and I can't seem to include the unmanaged either. New windows that are started aren't getting managed either. Here is the log: startuplog_2024-08-17.txt

Also looks very normal. What windows aren't being managed?

I might have an idea of what's going on though - could you alt+f while focusing one of the windows that are unmanaged?

[Xdavlar]

Sorry to say I can't do that, after (what feels like) my 20:th restart it suddenly started to manage all windows and everything seems fine. If I use alt+f it just maximizes them as intended. So I'm putting this down as the worst kind of error, the one that fixes itself and I don't know why. If you have a hunch I would be interested to hear it if I encounter this problem again.

[lars-berger]

Sorry to say I can't do that, after (what feels like) my 20:th restart it suddenly started to manage all windows and everything seems fine. If I use alt+f it just maximizes them as intended. So I'm putting this down as the worst kind of error, the one that fixes itself and I don't know why. If you have a hunch I would be interested to hear it if I encounter this problem again.

One of the v3 changes was initializing fullscreen windows as fullscreen rather than forcing them to be tiling. Someone made a similar report recently where a window wasn’t being managed and it turned out to be because they weren’t used to this new behavior and just needed to toggle fullscreen with alt+f. Were the unmanaged windows in your case initially maximized/fullscreen?

Only other thing I can think of is some other software interfering with the window positioning. Could anything else on the system affected the behavior - maybe even antivirus? There’s been a ton of changes but the underlying Windows api calls remain the same as in v2

[lars-berger]

Think there's a good chance this #726 fixed the root cause of this issue - it's the only difference between V2 and V3 in deciding what windows get managed. If someone runs into this issue again, LMK and I can reopen 👍