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]

https://github.com/rocksdanister/lively/blob/d5ca68c17663242c15580b55962364ac4061f89e/src/Lively/Lively/Views/WindowMsg/RawInputMsgWindow.xaml#L15

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]

https://github.com/rocksdanister/lively/blob/d5ca68c17663242c15580b55962364ac4061f89e/src/Lively/Lively/Views/WindowMsg/RawInputMsgWindow.xaml#L15

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.