You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off, thank you for creating what has been my trusty window manager for years now.
I've been experiencing a strange issue launching Marble-qt. After launching, it would spawn a window, which is promptly frozen and detached from the rest of the stack. This window stays in the foreground and persists between desktops, obscuring a portion of the screen. Closing Marble-qt will remove this window again.
Upon further inspection, the issue is reproducible with Bspwm and a blank config. The same issue also exists on Dwm, except that Dwm still manages the window.
@Darukutsu figured out that setting the config value external_rules_command to any value (doesn't have to be an existing executable file) makes the issue go away.
bspwm version: 0.9.10
Marble-qt version: 24.05.2
Distro: Artix Linux
The text was updated successfully, but these errors were encountered:
marble-qt seems to create and destroy 2 windows before the actual window is spawned.
what seems to be going on is that running right into manage_window() when e_r_c is null causes bspwm to manage a window that is about to be destroyed when the main loop processes xcb events.
when e_r_c is not null it delegates manage_window to the next main loop with add_pending_rule. that should cause unmap_notify to remove the pending rule before it's mapped (i think). i wonder if there is a side effect of using this for e_r_c == n
First off, thank you for creating what has been my trusty window manager for years now.
I've been experiencing a strange issue launching Marble-qt. After launching, it would spawn a window, which is promptly frozen and detached from the rest of the stack. This window stays in the foreground and persists between desktops, obscuring a portion of the screen. Closing Marble-qt will remove this window again.
Upon further inspection, the issue is reproducible with Bspwm and a blank config. The same issue also exists on Dwm, except that Dwm still manages the window.
@Darukutsu figured out that setting the config value
external_rules_command
to any value (doesn't have to be an existing executable file) makes the issue go away.bspwm version: 0.9.10
Marble-qt version: 24.05.2
Distro: Artix Linux
The text was updated successfully, but these errors were encountered: