<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <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#c33">Comment # 33</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 <a href="page.cgi?id=describeuser.html&login=jadahl%40gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> Jonas Ådahl</a> <pre>(In reply to Olivier Fourdan from <a href="show_bug.cgi?id=783901#c32">comment #32</a>) > (In reply to Jonas Ådahl from <a href="show_bug.cgi?id=783901#c31">comment #31</a>) > > Review of <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> <a href='review?bug=783901&attachment=354148'>[review]</a> [review] [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(). > > Well, it;s been a while since I wrote this patch, but I reckon this is not, > actually. The reason why I think it looks like this is that meta_window_force_placement() will call meta_window_wayland_move_resize_internal() which conditionally will set the window->rect.x/y. It seems to be that the condition should cover also this case. > > > 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? > > 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. How so? What difference would it make to cause the wayland_move_resize_internal() to save the rect.x/y compared to doing it outside? I'd only ever immediately save the position with the exact same conditions as in the attached patch, i.e. when not already placed before maximizing (by adding the MOVE_RESIZE_FORCE flag).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>