[Wayland-bugs] [Bug 783901] Restoring maximized window state in Wayland results in tiny window
mutter (GNOME Bugzilla)
bugzilla at gnome.org
Tue Jan 9 19:55:13 UTC 2018
https://bugzilla.gnome.org/show_bug.cgi?id=783901
--- Comment #32 from Olivier Fourdan <ofourdan at redhat.com> ---
(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20180109/49e7b995/attachment.html>
More information about the wayland-bugs
mailing list