<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#c21">Comment # 21</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#c20">comment #20</a>) > FWIW it still looks like a hack, doesn't seem right... But it improves > things. Yet another reason for (in the future) reworking window state tracking more thoroughly. Anyhow, I think this is reasonable as solution for now, but I wonder if we can't deal with the placement on unmaximize, by knowing that we don't have a saved rect to restore to, instead of coming up with one now. I mean, things might have changed while the window was maximized, and it makes more sense to calculate a "good" position close to when its to be positioned, not when it was initially maximized.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>