GNOME Bugzilla – Bug 645325
window rearrangement causes wrong window to be selected
Last modified: 2012-01-15 17:04:52 UTC
In overview when closing a window and afterwards dragging a window it can happen that you pick a wrong window or no window if windows' positions is updated while initiating the drag. Window arrangement update should start when leaving the windows area. Similar behaviour is implemented in google chrome when closing tabs.
Removing the delay before window rearrangement occurs might fix this. Renaming for clarity.
Removing the delay before window rearrangement will make closing multiple windows harder. (Closing three windows should be possible by localizing the three windows and clicking the three close buttons in a row without an interrupting rearrangement.)
(In reply to comment #2) > Removing the delay before window rearrangement will make closing multiple > windows harder. ... True. (In reply to comment #0) ... > Window arrangement update should start when leaving the windows area. ... A better solution might be to not rearrange the windows if the pointer is hovering over one of them.
Created attachment 204422 [details] [review] delay rearrangement when cursor hovers a window My patch aims to solve this as Allan proposed. BTW, I've found another little bug while testing my patch. When there's a delayed rearrangement (after I've closed a window), then I drag a window (nothing delays rearrangement anymore, so other windows are rearranged), then if I drop the window in the same workspace (cause I've changed my mind), the window goes to it's previous position, but it should go to its position after rearrangement. I doubt if we should be concerned about it, since it's really rare to happen, but if "Every Detail Matters" :).
(In reply to comment #4) > Created an attachment (id=204422) [details] [review] > delay rearrangement when cursor hovers a window > > My patch aims to solve this as Allan proposed. ... Keep 'em coming Vít! Can we have a patch and not a diff please?
Created attachment 204829 [details] [review] patch patch described earlier.
(In reply to comment #6) > Created an attachment (id=204829) [details] [review] > patch > > patch described earlier. Seems to have the desired effect.
Review of attachment 204829 [details] [review]: Just use global.stage.get_actor_at_pos() instead to find the actor under the pointer.
Created attachment 205068 [details] [review] patch (In reply to comment #8) > Review of attachment 204829 [details] [review]: > > Just use global.stage.get_actor_at_pos() instead to find the actor under the > pointer. Do you mean something like this?.
Review of attachment 205068 [details] [review]: Better but not there yet ;) ::: js/ui/workspace.js @@ +1180,3 @@ + for (let i = 0; i < this._windows.length; i++) { + if (this._windows[i].actor == global.stage.get_actor_at_pos(Clutter.PickMode.REACTIVE, x, y)) Store the result of the pick in a variable and use that in the loop. Don't pick in a loop.
Created attachment 205102 [details] [review] patch (In reply to comment #10) > Review of attachment 205068 [details] [review]: > > Better but not there yet ;) > > ::: js/ui/workspace.js > @@ +1180,3 @@ > > + for (let i = 0; i < this._windows.length; i++) { > + if (this._windows[i].actor == > global.stage.get_actor_at_pos(Clutter.PickMode.REACTIVE, x, y)) > > Store the result of the pick in a variable and use that in the loop. Don't pick > in a loop. I really have a lot to learn still. Thanks for patience.
Review of attachment 205102 [details] [review]: Code looks good. Fine to commit with this change to the commit message: "With this patch is window rearrangement delayed when cursor is in a window." -> "Fix that by delaying window rearrangement when cursor is over a window."
Created attachment 205259 [details] [review] patch (In reply to comment #12) > Review of attachment 205102 [details] [review]: > > Code looks good. > > Fine to commit with this change to the commit message: > > "With this patch is window rearrangement delayed when cursor is in a window." > -> "Fix that by delaying window rearrangement when cursor is over a window." I'm not entirely sure if I'm expected to upload the patch with altered message, but here it is.
(In reply to comment #13) > Created an attachment (id=205259) [details] [review] > patch > > (In reply to comment #12) > > Review of attachment 205102 [details] [review] [details]: > > > > Code looks good. > > > > Fine to commit with this change to the commit message: > > > > "With this patch is window rearrangement delayed when cursor is in a window." > > -> "Fix that by delaying window rearrangement when cursor is over a window." > > I'm not entirely sure if I'm expected to upload the patch with altered message, > but here it is. Pushed it for you http://git.gnome.org/browse/gnome-shell/commit/?id=b88b743 Thanks for the patch!
Yeah, thanks Vít! It's great to have this fixed.