Created attachment 183190 [details] [review]
workspaceView: Make sure to scale the workspace proportionally

Commit 0207f1f29b776ae5f8f59321284f1adc2f85159e landed a new
way of zooming, but was causing all sorts of window positioning
weirdness because the positions were supposed to be working against
a proportional workspace.

tagging ui-review per fmuellner's request

The ui-review issue here, if I remember the IRC conversation was:

 - Before the recent refactoring, the behavior when the sidebar slid out is that the entire workspace area shrunk, windows and all. This was the behavior in jimmac's mockup.

 - The current behavior is that the windows push together but don't rescale. There might be some issues with the details of the behavior - X and Y not changing the same, or windows overlapping, but that's secondary to the overall behavior.

I'm not quite sure where the need to avoid the scaling comes from. This design is consistent with making room for the context menu of all dash launchers. It was a mean to avoid overlaying the menu on top of the window thumbnails*, possibly preventing selecting one of them. I don't think there is a way to use the same 'compacting' solution there as well, as the menu is wider. 

In general I don't see fluid scale down of the window thumbnails as an issue.

* http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-window-picker-context-menu-pushes-windows-away.png

Review of attachment 183190 [details] [review]:

I'd like to suggest a small modification for clarity, otherwise the code looks good to commit.

::: js/ui/workspacesView.js
@@ +710,3 @@
 
+        let fullWidth = width;
+        let fullHeight = height;

In my opinion it reads more clearly if you reverse the above, e.g.

let fullWidth = this.actor.allocation.x2 ...
let fullHeight = ...

let width = fullWidth;
let height = fullHeight;

Attachment 183190 [details] pushed as a9505d0 - workspaceView: Make sure to scale the workspace proportionally