Created attachment 139873 [details]
sshot

<jnettlet> augias: walters: I tracked down that window creation problem.  It was a mutter commit actually.
<jnettlet> more specifically the launching a new window in the overlay being enormous
<walters> ah, interesting
<jnettlet> git commit 1f90529365f38efdafc4b85be1c4a5e048b5573f
<walters> well, there is a possibly related bug where when the app monitoring fails we keep around a reference to a bad window
 which is fixed in bugzilla
 jnettlet: hmm, maybe we need to connect to notify::allocation in the workspaces?
<jnettlet> walters: I was thinking about doing something like that
<jnettlet> definitely a little cleaner than an idle loop
<tf> jnettlet, what's the issue with 1f90529365f38efdafc4b85be1c4a5e048b5573f ?
<jnettlet> tf: well I don't think anything other than it breaks some of the shell code
<tf> are you cloning the window ?
<jnettlet> yes
<tf> and putting into something like ClutterGroup ?
<walters> yeah
<jnettlet> yep
<tf> you need to set a size on the clone
<jnettlet> put I was using the clone to set the size :-(
<tf> or put it into a proper container, not ClutterGroup :)
<walters> jnettlet: yeah, so inside workspaces.js, connect to notify::allocation on the source, and sync the size
 also sync the size initially
 tf: yeah, a proper container would be good...we really need js gobject subclassing
<tf> sorry, I forgot

*** Bug 591051 has been marked as a duplicate of this bug. ***

Created attachment 140177 [details] [review]
Use the size of the window, not of the clone to position windows

When Workspace._positionWindows is called, the clone might nto
yet have its final size (because of the clone is is a clone of
the window texture and the window texture isn't updated until
right before painting.) So get the size from the MetaWindow
instead ... the MetaWindow size is determined synchronously when
the window is managed.

Rebased to current master, added a comment, pushed.