<html>
<head>
<base href="https://bugzilla.gnome.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Restoring maximized window state in Wayland results in tiny window"
href="https://bugzilla.gnome.org/show_bug.cgi?id=783901#c32">Comment # 32</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Restoring maximized window state in Wayland results in tiny window"
href="https://bugzilla.gnome.org/show_bug.cgi?id=783901">bug 783901</a>
from <span class="vcard"><a href="page.cgi?id=describeuser.html&login=ofourdan%40redhat.com" title="Olivier Fourdan <ofourdan@redhat.com>"> <span class="fn">Olivier Fourdan</span></a>
</span></b>
<pre>(In reply to Jonas Ådahl from <a href="show_bug.cgi?id=783901#c31">comment #31</a>)
<span class="quote">> Review of <span class=""><a href="attachment.cgi?id=354148&action=diff" name="attach_354148" title="[PATCH 3/3] wayland: update location prior to maximize">attachment 354148</a> <a href="attachment.cgi?id=354148&action=edit" title="[PATCH 3/3] wayland: update location prior to maximize">[details]</a></span> <a href='review?bug=783901&attachment=354148'>[review]</a> [review]:
>
> ::: src/wayland/meta-wayland-xdg-shell.c
> @@ +355,3 @@
> + /* Make sure the position is up-to-date prior to call maximize */
> + window->rect.x = window->unconstrained_rect.x;
> + window->rect.y = window->unconstrained_rect.y;
>
> This looks like its working around something in force_placement().</span >
Well, it;s been a while since I wrote this patch, but I reckon this is not,
actually.
<span class="quote">> Shouldn't we fix this in meta_window_wayland_move_resize_internal()? It
> looks like we should be able to set "can_move_now" to TRUE if we are
> "!placed" (which will be set to TRUE after the move resize call), or
> possibly adding another MOVE_RESIZE flag "force" that forces the placement?</span >
That wouldn't be the same as saving the x/y when maximizing from
xdg_toplevel_set_maximized(), trying to address the issue in
meta_window_wayland_move_resize_internal() would either place the window
initially at 0/0 (thus defeating initial placement), or restore the location on
the wrong output, or play the initial mapping animation on the wrong output
(depending on which ig/then/else case we force "can_move_now" to TRUE) - Well
at least from what I saw when trying to experimenting with that, but I could be
wrong.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>