Created attachment 306690 [details] [review]
Set size hints for new wayland windows

Tried to dig into the positioning more, but that brought me only headache. This is quick and simple.

Review of attachment 306690 [details] [review]:

::: src/wayland/meta-window-wayland.c
@@ +352,3 @@
+   * The window will set its own size later via request */
+  attrs.width = 200;
+  attrs.height = 100;

Would it maybe be more reasonable to wait with creating the MetaWindow until proper attributes can be configured, i.e. not until after the first attached buffer is committed? Either that or support putting of initial mapping until so is the case. Having arbitrary initial size values doesn't seem like the best solution.

Review of attachment 306690 [details] [review]:

Seems like picking an arbitrary size could result in placement bugs - e.g., Mutter decides that the nice 300x300 gap in the lower left corner of the screen is the perfect place to put a 200x100 window, then it gets resized bigger and is mostly off the screen. I can't imagine that this is the correct approach.

It seems that *roughly* we should:
 - If placement is run when there is no buffer attached, return early and don't do it
 - Force placement when the buffer is attached if not already done

Created attachment 307232 [details] [review]
Do not force placing window if it is not mapped

Review of attachment 307232 [details] [review]:

::: src/core/window.c
@@ +1571,2 @@
        */
+      if (!window->placed && window->mapped)

This basically invalidates the purpose of this _force_placement() since window->mapped will always be false for the case where it matters (i.e. an X11 window that comes up minimized) and thus we'll never place it as intended here.

I think a better check than window->mapped here would be client_window_should_be_mapped (window) since this will let us skip the force_placement() for bufferless wayland windows but still do it for minimized X11 ones.

(In reply to Rui Matos from comment #5)
> Review of attachment 307232 [details] [review] [review]:
> 
> ::: src/core/window.c
> @@ +1571,2 @@
>         */
> +      if (!window->placed && window->mapped)
> 
> This basically invalidates the purpose of this _force_placement() since
> window->mapped will always be false for the case where it matters (i.e. an
> X11 window that comes up minimized) and thus we'll never place it as
> intended here.

Are minimized windows unmapped? They should be mapped...

(In reply to Jasper St. Pierre from comment #6)
> Are minimized windows unmapped? They should be mapped...

Yes, initially they are. Mutter maps them later, but when this function runs for the first time they are still unmapped. That's why I suggested checking client_window_should_be_mapped() since that will actually be true in this case while window->mapped is still false.

Created attachment 308853 [details] [review]
Do not force placing window if it has no buffer under wayland yet

Review of attachment 308853 [details] [review]:

Let's go with this

I still see this (or similar) issue with:
mutter-3.18.1-4.fc23.x86_64
gnome-shell-3.18.1-1.fc23.x86_64

I have secondary monitor on the left side and primary monitor on the right side. Nautilus is opened in 70% cases on the left monitor, in 30% cases on the right monitor (always in the very top left corner). Gnome terminal is always opened on the left monitor. This is regardless of where the mouse cursor is and where the app was the last time I closed it.

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