GNOME Bugzilla – Bug 613453
windows appear in random order in overview mode
Last modified: 2013-08-18 10:57:45 UTC
When in overview mode, the reason why windows are layed out the way they are seems a mystery to me, partly because the animation is too quick. Also when launching new apps on an already crowded workspace, the positions for these new apps also seem random (I've had them appear on spot #2 and the app after that on spot #4). We could make it behave more predictably. My suggestions: 1. Always put the active window on the top left spot. 2. Place the previously active window in the second spot. (1 and 2 make it behave more like the alt+switcher which works very well) 3. Make windows of the same application show up next to each other. 4. Newly launched apps should be given the last spot. (except when it's a new window of an already open app, in that case it should be right next to the already open window) There are probably more ways to get a better overview in The Overview :)
Our first setup was in stacking order - most recent app int the upper left, then next most recent, and so forth. Our experience with that was two problems: 1. It was annoying when windows were in different order every time in the overview - stability of positioning in the overview is important. 2. It looked bad when windows "crossed" when going to the overview. So the current algorithm is roughly: - Place windows so that motion going to the overview is minimized (this is stable as long the user doesn't move windows) - For ties (like all maximized windows), order by the order the windows were opened originally.
Ok so taking your points in my mind I can tweak me suggestions: 1. Can something else be done to remind me "what I was doing?". A visual change of the active window? 2. Not applicable anymore. 3. Grouping is worth breaking the stability (and it doesn't break all of it), because when you open a new window you already expect things to change. Having similar windows together makes sense. Right now I'm wondering why my inkscape windows aren't together and feels as if I have to "search" for the other one too much. 4. This suggestion still applies. Now they're appearing randomly in the stack. " - Place windows so that motion going to the overview is minimized (this is stable as long the user doesn't move windows)" This doesn't seem like a very good reason to me, at least at the moment. I can barely see where windows go now because the animation is too fast or drops frames (on an nvidia card :) ). Even when it's smooth I can maybe focus on two of them.
(In reply to comment #2) > Ok so taking your points in my mind I can tweak me suggestions: > > 1. Can something else be done to remind me "what I was doing?". A visual > change of the active window? Possibly - it's a little hard to think that would be, at least in the multiple workspaces case (in the single workspace you might be able to put a border around the window). > 2. Not applicable anymore. > 3. Grouping is worth breaking the stability (and it doesn't break all of it), > because when you open a new window you already expect things to change. Having > similar windows together makes sense. Right now I'm wondering why my inkscape > windows aren't together and feels as if I have to "search" for the other one > too much. We certainly can add grouping into the fallback ordering for ties - we just need *some* stable ordering, the use of ordering by open time isn't significant. In terms of grouping vs. minimum motion: - Minimized windows probably should be omitted from minimum motion - Windows under a maximized window probably should be omitted from minimum motion - If you have too many windows we already as I recall skip the minimum-motion computation because it's expensive, but I don't know if we do that in a sensible way. > 4. This suggestion still applies. Now they're appearing randomly in the > stack. I think basically what is happening is that we are moving windows so that the existing open windows move minimally, but likely we should reserve the last slot and only do that computation over the rest of the windows. > " - Place windows so that motion going to the overview is minimized (this is > stable as long the user doesn't move windows)" > > This doesn't seem like a very good reason to me, at least at the moment. I can > barely see where windows go now because the animation is too fast or drops > frames (on an nvidia card :) ). Even when it's smooth I can maybe focus on two > of them. It sounds like you have very many windows on the workspace - it can be a lot more obvious if only 2 or 3 windows are open. And dropping frames definitely isn't our intention! :-)
(In reply to comment #3) > (In reply to comment #2) > > Ok so taking your points in my mind I can tweak me suggestions: > > > > 1. Can something else be done to remind me "what I was doing?". A visual > > change of the active window? > > Possibly - it's a little hard to think that would be, at least in the multiple > workspaces case (in the single workspace you might be able to put a border > around the window). Hilighting somehow (several possibilies here) the focused app in the dash may help here. Also for keyboard navigation purphose I think it's important to be able to see which is the focused/selected window.
(In reply to comment #1) > Our first setup was in stacking order - most recent app int the upper left, > then next most recent, and so forth. Our experience with that was two problems: > > 1. It was annoying when windows were in different order every time in the > overview - stability of positioning in the overview is important. I wonder whether that would be alleviated by Hylke's suggestion - if you make placement predictable, stability becomes less of a problem... > 2. It looked bad when windows "crossed" when going to the overview. I'm not familiar with the mechanics, but would some kind of slight of hand be possible here? Is there any way that the crossing could be hidden?
Make windows placement predictable is very important. In most cases user can memorize where is his/her application's window last time it goes back to overview. New Windows Placement can be: a) First window must be always at top left. b) Subsequent new windows will be located at right of the last window. If new window require to add a new row, locate it at button left corner of the grid, like when you have two windows and add new one; or when you have six and add a new one. Close windows must have similar behavior, because you always want to now were will be your windows when remove others. Remove Windows placement can be: a) Close a window move the right one in the place of the closed one. b) All other windows in a grid must move to left, if a window is located at left side of a grid (the first window in a row), it must move at the right side of the upper row. c) Steps a) and b) must be cycle until all windows are located in a way to fill the space left by the closed window.
While I agree with the thought behind the bug, I don't think we can reconcile it with the demand to make the window thumbnails as large as possible. This makes the thumbnails much easier to recognise, and we managed to vastly improve the window selector in 3.8 by following this principle. Stability of layout is still worth considering, but that's better for another bug.