[Wayland-bugs] [Bug 771320] [Wayland] Maps widget is displayed at wrong position inside gnome-contacts

[gtk+ (GNOME Bugzilla)]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jadahl at gmail.com

--- Comment #15 from Jonas Ådahl <jadahl at gmail.com> ---
(In reply to Olivier Fourdan from comment #12)
> Created attachment 337492 [details] [review]
> [PATCH v2] gdkwindow: configure native windows in move_native_children()
> 
> (In reply to Jonas Ådahl from comment #11)
> > Review of attachment 337315 [details] [review] [review]:
> > 
> > ::: gdk/gdkwindow.c
> > @@ +5989,3 @@
> > +
> > +  display = gdk_window_get_display (window);
> > +  gdk_display_put_event (display, event);
> > 
> > Can be just "gdk_event_put (event);" since you do pretty much what that
> > function does here.
> 
> Yeah good idea, and I was leaking the event as well (since it's a copy that
> gets added tothe queue,  v2 fixes that.
>  
> > @@ +6013,3 @@
> > +        {
> > +	  configure_native_child (child);
> > +	  move_native_children  (child);
> > 
> > Can fix the coding style issue (double space) while at it.
> 
> Coding style is correct here, it's just that it uses a tab (8 char) so it
> shows weird in the patch. Anyhow, I replaced it with spaces, but there are
> tabs in many other places...
>  

I meant the double space between "move_native_children" and "(child);".

> > @@ +6102,3 @@
> >  			       window->width, window->height);
> >      }
> > +  else
> > 
> > How come this is needed? Shouldn't we still skip moving if the absolute
> > position didn't change?
> 
> Yes, that's precisely the problem... abs_x/abs_y can be wrong when
> transitioning from/to fullscreen/maximized/normal because the shadows and
> header bar get added/removed.

Ah, and at the time, the abs changes, the size hasn't caught up. I guess we
could add 'did-things-change' guards (i.e. check whether the size actually
changed before configuring) but I guess it doesn't hurt that much to let the
callee do that.

I wonder if we can change this in gtk+4 so that 'configure' and gdkwindow's
'size' is always without shadow, then let the shadow expand the backing
wl_surface size some other way, so we don't have all these races.

-- 
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/20161013/3eb0a146/attachment.html>