https://bugzilla.gnome.org/show_bug.cgi?id=783901
--- Comment #32 from Olivier Fourdan <[email protected]> ---
(In reply to Jonas Ã…dahl from comment #31)
> Review of attachment 354148 [details] [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.
> 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.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
wayland-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs