feat: hide and show windows via set_cloak from COM lib

[rpop0]

Previous method of hiding the windows (SW_HIDE and SWP_HIDEWINDOW) would completely remove the window from the taskbar, which would lead to unexpected behavior for some people. set_cloak allows the hidden windows to still be present in the task bar.

Other discussions on the topic: Ciantic/AltTabAccessor#1

This PR also would close #416

[rpop0]

Draft, looking into having the cloaking functionality to be toggled in the config, allowing users to switch between cloaking and the previously used methods.

[rmanthorpe]

@rpop0 I've been running this branch this morning and it also seems to #250, thank you so much! I also haven't run into #759 yet using this version so it might have fixed it.

Edit: I'm very sure #250 and #759 are fixed by this change - I haven't seen a single issue with an electron app or Excel all day!

[rmanthorpe]

Draft, looking into having the cloaking functionality to be toggled in the config, allowing users to switch between cloaking and the previously used methods.

Can we do this on a per-application basis? I suspect we will find that some applications (like Excel) only work with this method whereas others work better with the original.

I'm finding that MS Outlook doesn't have well with this method. Correctly belongs to a workspace but it won't tile, it's always full screen, even covering the zebar no matter what else I put in the same workspace.

[rpop0]

Draft, looking into having the cloaking functionality to be toggled in the config, allowing users to switch between cloaking and the previously used methods.

Can we do this on a per-application basis? I suspect we will find that some applications (like Excel) only work with this method whereas others work better with the original.

I'm finding that MS Outlook doesn't have well with this method. Correctly belongs to a workspace but it won't tile, it's always full screen, even covering the zebar no matter what else I put in the same workspace.

Hm, from what I quickly tested now it seems like Outlook just crashes the window manager when being started, leading to it not tiling. I'll investigate it and see why that happens.

[rmanthorpe]

it seems like Outlook just crashes the window manager when being started

You're quite right, it does indeed. I already had outlook open when I started glaze which led to the behaviour I saw.

[rpop0]

@rmanthorpe I think I may have found a fix.

Can you try adding the following rules under the ignore command and see if the crash still happens?

- window_process: { equals: 'explorer' }
  window_class: { equals: 'ApplicationFrameWindow'}

[rmanthorpe]

Can you try adding the following rules under the ignore command and see if the crash still happens?

It still crashes I'm afraid. What I'm seeing (with or without that rule) is that opening outlook with glaze running crashes glaze but starting glaze with outlook running is fine and outlook is working perfectly normally. I'm not sure what happened the first couple of times where outlook wouldn't tile, I can't reproduce that behaviour now!

[rpop0]

Can you try adding the following rules under the ignore command and see if the crash still happens?

It still crashes I'm afraid. What I'm seeing (with or without that rule) is that opening outlook with glaze running crashes glaze but starting glaze with outlook running is fine and outlook is working perfectly normally. I'm not sure what happened the first couple of times where outlook wouldn't tile, I can't reproduce that behaviour now!

So the ignore rules I provided above fix another crash, related to the login screen which MS uses for their apps (Login popup to sign in to Microsoft)

I think I narrowed down the issue to the splash screen shown when loading Outlook. WinLister also happens to crash when starting outlook.

Try adding the following rule to ignore, separate from the previous rules:
- window_class: { equals: 'MsoSplash' }

[rmanthorpe]

Try adding the following rule to ignore, separate from the previous rules:
- window_class: { equals: 'MsoSplash' }

Yes! That has done the trick! This change is amazing is has had such a big impact on me today. I'm going to keep using this branch until it is merged.

[rpop0]

@rmanthorpe The most recent commit should make the window manager more resistant to windows with weird behavior that would previously crash. While the rules I specified are longer really needed, they still provide a nicer experience by just ignoring those problematic windows.

[rmanthorpe]

The most recent commit should make the window manager more resistant to windows with weird behavior that would previously crash.

Tested and confirmed - removed the config and Outlook is working well without it!