GNOME Bugzilla – Bug 576269
Windows aligned in diagonal row in overlay mode
Last modified: 2009-08-09 19:09:44 UTC
In the overlay mode the windows are aligned to hardcoded positions if there are fewer than 5 windows on a workspace. If there are more than 5 windows, the overlay mode places them in a diagonal row. This certainly makes the titles visible but hides most of the windows. I have made a patch that puts them in a grid layout if there are 6 or more windows on a workspace. Other information:
Created attachment 131111 [details] [review] Aligns 6 or more windows in a grid in the overlay mode. Don't use this patch. Use the new one.
Can you redo the patch so that: A) It doesn't have any FIXME's (comments explaining alternate ways of doing things are fine) B) You remove the old code and irrelevant comments, that's what version control is for. Also, does: let pos = (numberOfWindows - windowIndex - 1) / (numberOfWindows - 1); let xCenter = (windowIndex % gridWidth) * pos; let yCenter = (windowIndex / gridWidth) * pos; Really give you a regular grid?
Created attachment 131592 [details] [review] the actual patch You're right on all counts Owen. The patch I sent would have patched from the old version to a broken intermediate version(mixed up two files :( . This is the actual patch.
Created attachment 131807 [details] [review] This is the attachment using git Since GNOME Shell is using git now, I created the patch with the git version.
Thanks for redoing the patch against git. Tried the patch out and the behavior looks pretty good. Few small comments on the patch: + let fraction = Math.sqrt(.5/(gridWidth*gridHeight)); + + let pos = (gridWidth*gridHeight - windowIndex - 1) / (gridWidth*gridHeight - 1); Neither of these variables look like they are used. + let xCenter = (.5 / gridWidth) + ((windowIndex) % gridWidth) / gridWidth; + let yCenter = (.5/ gridHeight) + Math.floor(((windowIndex) / gridWidth))/gridHeight; /gridHeight should have spaces around the '/. And you should remove parenthesis around (windowIndex) since they aren't needed. I think a nice enhancement beyond this would be to use the same ordering algorithm that is used for workspaces so when you add another window to a workspace changing the numbers of rows and columns it doesn't completely rearrange all the windows. But why don't you do the fixes above, and then we can get this patch in, and treat that as a separate enhancement. Once you make the changes above, you should commit your changes with 'git commit', and then use 'git format-patch HEAD -1' to create a patch to attach - that way I'll be able to apply it with the right author and commit message. Take a look at 'git log' to get an idea of what your commit message should look like.
Created attachment 131810 [details] [review] Changed window arrangement in the overlay to a grid pattern for 6 or more windows
Created attachment 131812 [details] [review] Use a grid pattern in overlay if more than 6 windows.
Created attachment 131964 [details] [review] Arrange windows in grid the same way as workspaces This will stop windows shifting around when the grid resizes.
Looks like it would work fine. From an ideological standpoint, I'm not completely comfortable with an O(n**2) algorithm where for every window we lay out all the windows. (For the workspaces, we do all the workspaces in one loop so the O(n**2) doesn't come up.) In practice, it probably doesn't matter unless you have 1000 windows. If you think about the layout algorithm as being a series of "shells" numbered 0 (the window at top left), 1 (the next three windows), 2 (the next 5 windows), etc, then you could come up with a closed-form expression for the row and column of a window with something like: shell = floor(sqrt(WI)); pos_within_shell = WI - shell**2; if (pos_within_shell <= shell) { row = pos_within_shell; col = shell + 1; } else { row = shell + 1; col = pos_within_shell - (shell + 1); } You could even have a function that did this, and use it both for windows and workspaces. [row, column] = _shell_layout_row_column(WI). Do you also need to adapt the '5' layout from the fixed layouts so that the transition from 5 to 6 works as expected? - I think the current '5' layout is 1 2 3 4 5
I'm closing this bug as the windows are displayed in a grid now. From the last message I'm not sure if there were any outstanding issues, but the positioning algorithm needs to be revised anyway (and as I said on IRC I may have a look at it within the next weeks).