Lively WndProc and Lively WndProc (Input) invasive windows when using GlazeWM window manager

[seanpden]

Describe the bug
"Lively WndProc" and "Lively WndProc (Input)" windows pop up on launch. I cannot minimize these windows, and when I close them I cannot access the system tray context menu of Lively. Additionally, when the previously mentioned windows are closed and I try to change the wallpaper, I receive an error message "Object reference not set to an instance of an object. Exception: Exception."

To Reproduce
Steps to reproduce the behavior:

1. Open Lively
2. See two windows
3. Close windows
4. Change wallpaper
5. See error in GUI

Expected behavior
I didn't expect the two windows to pop up, I expected to run the application and have the wallpaper effects without additional windows.

Screenshots/Video

Desktop (please complete the following information):

• OS: Windows 10 Pro 22H2 19045.3570
• Windows Manager: GlazeWM
• Wallpaper: Any

Additional context
Add any other context about the problem here.
I am using a windows manager, GlazeWM. I've tried ignoring the windows in my glaze config, but the issue still persists. I'm not sure if this is contributing.

Log file (Important)
Share the diagnostic files by:
Open Lively settings (Gear icon) top-right -> System -> Log File -> Save
or
Navigate to Appdata folder C:\Users\<UserName>\AppData\Local\Lively Wallpaper\logs
lively_log_20240701_173032.zip

[rocksdanister]

These two window are used by the core for listening to mouse/keyboard input and system messages. They are hidden and opened outside monitor region with taskbar icons disabled; the problem is the third party window manager is moving it in front.

If the ignore option is not working with the tool then not sure what else I can do, this is not a bug on my side and everything works as expected in a regular system.

[lars-berger]

These two window are used by the core for listening to mouse/keyboard input and system messages. They are hidden and opened outside monitor region with taskbar icons disabled; the problem is the third party window manager is moving it in front.

If the ignore option is not working with the tool then not sure what else I can do, this is not a bug on my side and everything works as expected in a regular system.

Hey @rocksdanister, it'd be possible for us to advise users of Lively to add an ignore rule for it in their GlazeWM config. However, it doesn't appear as though the input windows are actually spawned as hidden in this case. One of the main checks we have is whether a window has WS_VISIBLE, and you can see from the screenshot above that these are graphical windows with a white background. If you'd like to better support 3rd-party apps like GlazeWM, ensure that WS_VISIBLE is not present when creating these windows.

[rocksdanister]

lively/src/Lively/Lively/Views/WindowMsg/RawInputMsgWindow.xaml

Line 15 in d5ca68c

Visibility="Hidden"

That's weird, it is set as hidden in settings.
But thinking about it I am not sure if its possible to listen to RawInput with a completely hidden window 🤔

[lars-berger]

lively/src/Lively/Lively/Views/WindowMsg/RawInputMsgWindow.xaml

Line 15 in d5ca68c

Visibility="Hidden"

That's weird, it is set as hidden in settings. But thinking about it I am not sure if its possible to listen to RawInput with a completely hidden window 🤔

We actually happened to also started using the raw input API in the Rust rewrite of GlazeWM, and it's been working fine as hidden (registering for raw input and creating the window).

Not sure about the behavior of Visibility="Hidden" - are there any ShowWindow calls? Is the behavior different with Visibility="Collapsed"? You can also try ShowWindow(handle, SW_HIDE) on source initialized.

[rocksdanister]

Thanks but there is also a window for WNDPROC. I'll update the wiki with the exception rule.