GNOME Bugzilla – Bug 166524
metacity placement algorithm causes IM windows to get buried beneath other larger windows
Last modified: 2005-02-15 19:40:30 UTC
Please describe the problem: Using metacity 2.9.8 with autoraise. If I receive an IM and I have a browser window focused, it will often be placed in the same area as the browser window and beneath it so I never knew the IM came in unless I happen to notice it in the window list. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
The placement algorithm assumes all windows will be focused and appear on top; we need to modify it so that if a window will not be focused on map then it has the least amount of overlap with the focused window as possible, unless it is a transient of the focused window (since then it will appear on top anyway). I've also missed some windows for a long time this way, though none of them were IMs or anything important so it didn't seem that big a deal to me and I didn't think twice about it. Another way to assist in fixing the problem here would be to find a better way to display the demands_attention hint (bold text in the tasklist is not that noticable and is also highly confusing since Firefox using that in tabs to mean the currently active tab). However the only other solution I can think of is blocking on bug 150594.
Yes the bold text is too hard to spot. But you can't do blinking in a compatible way. So I'm not sure what to do. Maybe a notification popup?
> So I'm not sure what to do. I'm not quite sure what you have in mind by "a notification popup", but IMO we should do two things: (1) Try to make sure the window appears on the screen even if it isn't focused (which is what this bug is about), (2) convince Owen that changes should be made to make it possible to do blinking in a way that works for all themes (but that's a separate bug, namely bug 150594, so I probably shouldn't have brought it up).
I'm talking about the hypothetical notification system coming out of freedesktop.org at some point. It would be a little window that would appear briefly on screen in the corner that lets you know what happened. Maybe we could do a little animation. Who knows.
We could always try the appalling hack I suggested for button flashing on bug 120439. ;-) I'm not sure whether it would work.
Ooh, I forgot about that suggestion. That looks like fun. Bwahaha. (Too bad there's so many other bugs to look at first and so little time...)
Okay, so I've got a patch put together and ran it through a couple tests. This patch: 1) Adds a denied_focus_and_not_transient bitfield to window.h, so that we can key off it in meta_window_place to determine whether we have to worry about where the focus_window is when placing this new window. 2) For such windows, if they are normally placed such that they don't overlap the focus window, then do nothing extra. Otherwise: 3) Retry the first-fit algorithm, but this time paying attention *only* to the focus window. 4) If that still doesn't find a location disjoint from the focus window, find the location on the screen adjacent to the focus window which will show as much of the new window as possible. While I think I have it right, comments and testing are very welcome. I'll attach the patch momentarily.
Created attachment 37225 [details] [review] avoid new windows being obscured by the focus window (and thus possibly lost)
Elijah, I'll test this out tonight and let you know.
Created attachment 37319 [details] [review] New version; don't place windows partially offscreen This new patch just adjusts the behavior when the window is placed to the right or the bottom of the focus window. In those cases, it makes the window's right or bottom edge align with the edge of the screen while the remainder of the window is hidden behind the focus window (as opposed to previous patch would would make the left or top edge of the window align with the focus window and make the remainder of the window be hidden offscreen). Crispin tested out both patches, and pointed out that as long as the same amount of the window is showing in both cases, its more useful to have the window be onscreen so that when the user switches to it they don't have to manually move it themselves.
Comment on attachment 37319 [details] [review] New version; don't place windows partially offscreen Remember that fgeom can be NULL for undecorated windows, iirc. Some missing spaces around operators and before parens I'd make an enum instead of just "side = 0" Looks reasonable in the big picture, thanks.
Created attachment 37327 [details] [review] Fixed up version
I just applied this patch and it seems to improve the IM loss problem.
committed.
Elijah : do you take the panel into account when trying to make the window stay onscreen ? With CVS, when I get browser windows opening in the background, the bottom of the window is hidden behind the bottom panel. So I have to move them, defeating the purpose ;-)
Yes, for me the bottom edge of the window will be placed immediately above the panel. Can you provide exact steps to reproduce, and perhaps a screenshot?
Well I'm using blam to read RSS feeds, and this happens when I click on a link to open the article in an epiphany window. The epiphany window appear below the blam window, stuck to the bottom-left corner of the screen, and also below the panel...
Created attachment 37504 [details] screenshot This cropped screenshot shows the bottom-left part of my screen. I clicked on the "Show in browser" link in blam and the epiphany window on the left opened. I tried to move the bottom panel on other sides of the screen, and actually the epiphany window is *not* fixed to the bottom of the screen : the bottom of the window is actually off-screen, so it's not related to the panel... Any idea on how to debug this ?
You could try getting a verbose debugging log (grep for METACITY_VERBOSE=1 in the HACKING file of Metacity), which may help. Unfortunately, meta_window_place() in place.c doesn't have as much debug spew as what I'd like, so I'm not sure if this will be helpful or not. We may need to sprinkle some more meta_topic's (or meta_warning's if you want to be able to see specific messages at the terminal and don't want to look through a huge debugging log) throughout that function.