GNOME Bugzilla – Bug 339371
Window List has bad behavior with sloppy mouse focus
Last modified: 2006-08-12 16:35:19 UTC
Please describe the problem: First set Metacity to have sloppy mouse focus without raise on mouse over. Now set one window over most of another. Set the behind window so that it is in the path between the top window and the Window List applet. Now suppose I want to raise the behind window by using the window list. I move my mouse down towards the windows list. In the process, without realizing it, my mouse slides over the window I want to raise. Now I click on its entry in the window list and instead of raising the window it minimizes it. The exact opposite of what I wanted. I feel window list should only minimize if the window is also raised. I wasn't sure if this was a metacity bug or a window list bug. Sorry if this is the wrong product. Steps to reproduce: 1. Set metacity to sloppy focus without raise on mouse over 2. Set windows as described abover 3. Move mouse to window list to raise the behind window 4. Enjoy frustration as it minimizes instead of being raised Actual results: the window minimizes Expected results: the window raises to the top Does this happen every time? Only when the mouse travels over the window on the way to the panel Other information:
This problem occurs for me as well. I really like using sloppy focus but this bug can make it very fustrating. I think this bug is a window list problem, but I don't know for sure. I think I might have a better look at it...
Created attachment 67600 [details] [review] fix for weird behaviour with sloppy focus on the window list This patch should fix the issues experienced. It probably needs someone to check if this is the expected behaviour. For me anyway it makes the task bar almost worth using ;). I think I will attempt to fix the sporadic size changing problems next...
When playing around with the patch it can act a little "strange" for a window that has no window on top of it but it has focus. If you click on the window in the task list it will bring it to the front but you do not notice a difference. So I think the required change will be to check if any other windows overlap the one that is being clicked. I will have a look at this in a few days time.
Hi Stephen. Your patch isn't readable for some reason I ignore. Can you attach it again? Also, this is most probably a libwnck bug. Moving there.
Sorry it's a .tar.bz2 with patch files. And yes it is a libwnck bug that's what the patch is for. The patch should not be merged though because it has a slight regression. Which I'll fix soon ;)
Ok I spent some time on it tonight. The behavior is as expected. If you use sloppy focus and try and bring window "a" forward (because another window overlaps it) and by going to the window list you change focus to window "a", then it brings it forward. My patch has one flaw overlapping decorations does not count as overlapped. that is not solvable easily - there is no way to tell how big the window is including the decorations in libwnck.
Created attachment 70768 [details] [review] Patch to fix this incorrect behaviour (for libwnck)
Cool, good to see someone working on this. Some comments: I really prefer the meta_rectangle_overlap() implementation from metacity/src/boxes.c to the wnck_window_is_overlapping() implementation. Since libwnck and metacity already share some code, I'd prefer keeping something like this a bit more similar; perhaps cut and paste the function from there? I don't understand why you are using !wnck_window_is_skip_tasklist (window_pos); as part of the check for whether the window is valid. That doesn't make any sense to me. Your patch will also have problems with windows marked as being "On Top"/"Above". If an "On Top" window overlaps a normal window, the normal window *can't* be raised above the "On Top" window. Because of that, your patch makes it impossible to minimize the window via the tasklist, and, in fact, doesn't do anything when the user clicks on the tasklist button. > My patch has one flaw overlapping decorations does not count as overlapped. > that is not solvable easily - there is no way to tell how big the window is > including the decorations in libwnck. I was surprised by this, but did a grep for _NET_FRAME_EXTENTS and indeed libwnck does not yet support it. We didn't even have a bug report for it yet. So I filed bug 351055. Anyway, this is bug 90134 so I'm going to mark as a duplicate. Feel free to attach any further patches there. (Though, if you add support for _NET_FRAME_EXTENTS, make sure that patch goes to bug 351055.) Thanks for working on this! *** This bug has been marked as a duplicate of 90134 ***