GNOME Bugzilla – Bug 650661
Blue rectangle drawn above the window when tiling if another window is marked as “always on top”
Last modified: 2011-07-09 00:58:45 UTC
If a window is marked as “always on top”, and another window is dragged to one of the edges in order to tile/maximize it, the blue rectangle which is usually drawn below the window being dragged is drawn below the “always on top” window, that is, above the window being dragged. Performing the test with two “always on top” windows shows clearly that the blue rectangle is always drawn below the window at the top of the focus stack.
(In reply to comment #0) > Performing the test with two “always on top” windows shows clearly that the > blue rectangle is always drawn below the window at the top of the focus stack. Right. Reassigning to mutter, which is were tiling is implemented.
Created attachment 188229 [details] [review] core: Improve lower_beneath_focus_window() The code assumed that the focus window was always the one at the top of the window stack, which is not true if an unfocused window has the above hint set. To fix, iterate over the stack if necessary until the actual focus window is found.
By the way, I think the fix makes a good candidate for 3.0.2, so a quick review would be appreciated.
Review of attachment 188229 [details] [review]: What if we replaced lower_beneath_focus_window() with lower_beneath_grab_window()?
(In reply to comment #4) > Review of attachment 188229 [details] [review]: > > What if we replaced lower_beneath_focus_window() with > lower_beneath_grab_window()? And use display->grab_window? Sure, would work for me ...
(In reply to comment #5) > (In reply to comment #4) > > Review of attachment 188229 [details] [review] [details]: > > > > What if we replaced lower_beneath_focus_window() with > > lower_beneath_grab_window()? > > And use display->grab_window? Sure, would work for me ... Seems that is what we want - I was spending a lot of time poking around trying to figure out if there was ever a case where the focus window wasn't the window being dragged about (like maybe not-focusable windows), but it struck me that if we want the grab window, we should use the grab window.
Created attachment 191545 [details] [review] core: Replace lower_beneath_focus_window() The code assumed that the focus window was always the one at the top of the window stack, which is not true if an unfocused window has the above hint set. Rather than fixing this assumption, rename the function to lower_beneath_grab_window() and use the display's grab window - the function is only used for displaying the tile previews, which means that we want the grab window anyway.
Comment on attachment 188229 [details] [review] core: Improve lower_beneath_focus_window() (In reply to comment #6) > Seems that is what we want - I was spending a lot of time poking around trying > to figure out if there was ever a case where the focus window wasn't the window > being dragged about (like maybe not-focusable windows), but it struck me that > if we want the grab window, we should use the grab window. Yeah, the function is only used to show the tile previews, so we do want the grab window. I don't remember why I didn't use that in the first place, maybe because the grab window can be more obviously unset?
Review of attachment 191545 [details] [review]: Looks good
Comment on attachment 191545 [details] [review] core: Replace lower_beneath_focus_window() Committed (with git-bz bailing out for some reason) ...