[Bug] Regression in GlazeWM 3.4.0 overlaying with Taskbar

[anthonymendez]

Describe the bug

Hello, I realize that this may not be the right place but I figured I report this considering GlazeWM users may also use Windhawk or other Taskbar modifying programs :)

With the recent update, I noticed that the overlay isn't working as expected with my custom taskbar. I've modified the taskbar with Windhawk using:

• Taskbar Clock Customization
• Taskbar height and icon size
• Taskbar Labels for Windows 11
• Taskbar on Top for Windows 11
• Windows 11 Taskbar Styler

The big issue is that the windows go under the taskbar on my main monitor. Then when I adjust the padding to compensate for this, my 2nd monitor with no taskbar has a large gap at the top with the programs.

Version 3.3.0 Example:

Version 3.4.0 Example:

My config.yaml:
config.yaml.txt

Reproduction

No response

Stack trace or error logs (if applicable)

No response

Version number

3.4.0

[Geobert]

I can confirm with StartAllBack on Win 11

[isaac-varg]

Also having this issue with Windows 11 and Start11 with the taskbar positioned on top.

[JonasWischeropp]

Does it help to set gaps.scale_with_dpi to false?

gaps:
    scale_with_dpi: false

[isaac-varg]

Configuring scale_with_dpi to false did not seem to help.

I attempted to change the gaps.outer_gap.top to a higher value to avoid the taskbar and the issue persisted. The issue did resolve when I move my taskbar to be positioned at the bottom.

[Dovias]

Can confirm on GlazeWM 3.5.0.

As far i've tested it it seems to happen only in those cases where specified top outer gap is being set smaller than 50 px. Strangely enough this matches the windows 11 taskbar size for me. Top taskbar alignment is currently wonky on Windows 11 sadly (you can also move XAML based taskbar to the top with Windhawk mods, but then you get notification center and control center panel alignment issues) 😢

I'm pretty sure this can be fixed with some kind of hook to StartAllBack and ExplorerPatcher, since Windows 11 for some odd reason removed the taskbar alignment feature.

[Dovias]

Update 1: after thorough investigation of the code, I found a bug inside GlazeWM handling of working_rect objects. For some odd reason taskbar adjustment offset becomes negative which causes this weird behaviour which I was able to fix temporarily on my dev build. I might do PR to fix this soon.

Update 2: I found the culprit. apply_delta() and apply_inverse_delta() functions inside rect.rs file seems to apply delta offsets without respecting the direction of the taskbar. Inverting scale_factor depending on the on direction may fix this issue.

Update 3: Opened a PR with a fix for this issue, see below this message 👇

[github-actions]

🎉 This issue has been resolved in version 3.6.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 3.6.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀