[Wayland-bugs] [Bug 769402] regression in menu positioning on wayland

[gtk+ (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=769402

Jonas Ådahl <jadahl at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #332789|0                           |1
        is obsolete|                            |

--- Comment #13 from Jonas Ådahl <jadahl at gmail.com> ---
Created attachment 332911
  --> https://bugzilla.gnome.org/attachment.cgi?id=332911&action=edit
wayland: Postpone processing move_to_rect params until showing

At the time of move_to_rect() is called, not all state may have been set
up on the impl gdk window, causing the position to sometimes be
slightly offset due to drap shadow margins. For now, work around this
by postponing the processing of the move_to_rect() parameters until
showing, when its more likely that all state (such as shadow margin)
has been set correctly.

----

I give up on getting resizing working properly in the Wayland backend for now,
and work around it by postponing the calculations that depend on a fully set up
state.

The problem is that, if I understand things correctly, GdkWindow::width/height
are including shadow margin dimensions, which causes problems when changing
state changes the existance of drop shadows.

For example, assume that we have a maximized window thus without drop shadow.
We get a configure request telling GTK to unmaximize the window and use the
size of the configure request (i.e. the requested window geometry - window size
excluding shadow margin). GDK will then use this size, append the 0-sized
shadow margin, and emit a GDK_CONFIGURE request with the new size. GTK will
then add a shadow region, but without resizing the allocation, resulting in a
slightly smaller window. Maximize->unmaximize->maximize a few of times and your
window is suddenly tiny.

We'll see the same problem when going the other way: assume we have a
unmaximized window, and the compositor asks it to maximize itself. It'll take
the window geometry dimension it got from the compositor, append the shadow,
and emit a GDK_CONFIGURE event. GTK will then take the dimension of the
configure event, remove the shadow without resizing the allocation, resulting
in a too large window.

A possible solution is to add private state to GDK_CONFIGURE, with a window
*geometry* rect set, that is always excluding shadow width. Not sure I like
this solution very much, because it'll leave the dimension of the GdkConfigure
event still somewhat useless.

-- 
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/20160808/c9b42151/attachment.html>