<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - tiled (snapped, half-maximized) windows in Wayland aren't GDK_WINDOW_STATE_TILED" href="https://bugzilla.gnome.org/show_bug.cgi?id=766860#c19">Comment # 19</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - tiled (snapped, half-maximized) windows in Wayland aren't GDK_WINDOW_STATE_TILED" href="https://bugzilla.gnome.org/show_bug.cgi?id=766860">bug 766860</a> from <a href="page.cgi?id=describeuser.html&login=ofourdan%40redhat.com" title="Olivier Fourdan <ofourdan@redhat.com>"> Olivier Fourdan</a> <pre>(In reply to Jonas Ådahl from <a href="show_bug.cgi?id=766860#c18">comment #18</a>) > Those changes are not directly related to tiling, they are more about > negotiating the "state" of which a surface is drawn. In the wip we have so > far introduced a "no drop shadow" state. All these states are supposed to be > optional, and guaranteed to be respected when supported. I fail to see "no drop shadow" as a state to be honest, but that's another topic. > I think it might make sense to have tiling state part of the "window state" > enum, and and probably tiling edges. For example, I suspect a "no_shadow" > mode would mean we still have rounded corners, but a "tiling" mode, we'd > have sharp corners. I reckon possible tiling state(s) discussions should be driven by developers of tiling WM/CM, because as far as I am concerned, I reckon "tiled" in itself is sufficient, anything more precise (thus as edge tiling) might end up being restrictive, we could have tiling WM/CMs who tile windows in random places on screen, not just screen edges. But then again, we should discuss that on wayland-devel ML for a broader audience.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>