GNOME Bugzilla – Bug 690313
Overview window arrangement is not optimal
Last modified: 2013-02-18 11:02:53 UTC
Look at the attached screencast. There is one right tiled Emacs, and one maximized Terminal. Yet, my emacs ends on the left of the terminal, meaning that it travels all the screen horizontally when I open the overview. And it looks weird.
Created attachment 231678 [details] Screencast showing the suboptimal layout
Right now windows are sorted by serial. Adding a sort by distance would complicate matters, but feel free to try.
Oh really? That's not how it used to be before the refactoring...
Yes, that functionality was removed during overview relayout. Before, we had a set of predetermined slots, so it was only factorial combinations. I suppose you could try to have a hint to the strategy about positions, so it would favor a LEFT, CENTER or RIGHT-influenced window based on where it is on the screen
I've also noticed this bug since the window thumbnails were redone. It is mostly noticeable when you have two windows open and they switch positions for the overview, and is at its worst when you have two half-maximised windows. Considering the latter, it would be good to present half-screen snapped windows as a single thumbnail - which would solve that particular instance of this bug.
(In reply to comment #5) > I've also noticed this bug since the window thumbnails were redone. It is > mostly noticeable when you have two windows open and they switch positions for > the overview, and is at its worst when you have two half-maximised windows. > > Considering the latter, it would be good to present half-screen snapped windows > as a single thumbnail - which would solve that particular instance of this bug. What do we do if you have two windows snapped to the right, and one snapped to the left?
Created attachment 232213 [details] [review] overview: Sort windows by x coordinate Use the x coordinate instead of the stable sequence so that the ordering / moving feels more natural. ----- This is a very simple patch, but the results look much better then just using the stable_sequence ... and seems to fix the half maximized window issue as well. I didn't really read the surounding code so I might be missing something but given that the sequence was kind of arbitary and this seems to be better in testing ...
(In reply to comment #6) > > Considering the latter, it would be good to present half-screen snapped windows > > as a single thumbnail - which would solve that particular instance of this bug. > > What do we do if you have two windows snapped to the right, and one snapped to > the left? The idea would be that the first two windows that are visible and half-screen snapped would be counted as a single unit. Subsequent half-screen snapped windows would not be "joined" on. To remove a window from the joined unit, you would un-snap them.
It should be said that, due to the complexities to the approach I've described, a simpler solution would certainly make sense. The patch in comment 7 sounds promising.
Or you could just pick a layout as right now, but then after layout sort each row so that its in the order that minimizes the total distance traveled during the animation.
Created attachment 236442 [details] [review] overview: Sort windows by travel distance within rows Sort windows inside the rows by there travel distance. OK here is a new try at improving this.
Created attachment 236443 [details] [review] overview: Sort windows by travel distance within rows Sort windows inside the rows by there travel distance. Removed useless whitespace.
Review of attachment 236443 [details] [review]: Second half of the patch seems unrelated? Seems like a good cleanup, but unrelated...
(In reply to comment #13) > Review of attachment 236443 [details] [review]: > > Second half of the patch seems unrelated? Seems like a good cleanup, but > unrelated... Not really the windows are assigned to the slots when creating the slots "slots.push([x, y, s, window]);" so we have to iterate over the slots and not the clones when placing them. Otherwise we would still place the windows based on the stable sequence.
Review of attachment 236443 [details] [review]: Ah, OK.
Attachment 236443 [details] pushed as 9936f97 - overview: Sort windows by travel distance within rows