[Wayland-bugs] [Bug 771112] some applications windows to grow on startup (with CSD)

[gtk+ (GNOME Bugzilla)]

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

--- Comment #14 from Emmanuele Bassi (:ebassi) <ebassi at gmail.com> ---
(In reply to Kai Willadsen from comment #11)
> (In reply to Emmanuele Bassi (:ebassi) from comment #7)
> > Querying the window size and then setting it with GtkWindow API is perfectly
> > fine.
> > 
> > Querying the window size with GtkWidget API and then setting it with
> > GtkWindow API, *or* querying the window size with GtkWindow API and then
> > setting it with GtkWidget API, is *not* okay, and only worked up until now
> > with server-side decorations only on X11.
> 
> In the current GtkWindow docs for gtk_window_get_size(), the second and
> fourth notes directly contradict each other, and I'm pretty sure the first
> paragraph is now also incorrect.

Indeed; the documentation was likely written for GTK+ 2.x or even before that,
when we did not have support for Wayland or for client-side decorations.

> I don't know what these other apps do, but
> Meld's implementation here listens for configure-event and uses those sizes,
> which is pretty much exactly what the first note there tells you to do.

Yep, and that's really not how you should do this; the configure-event signal
is an X11-ism, even though GTK+ tries to map it to other windowing systems.

The appropriate way to get a notification of a size change in a widget is to
use the GtkWidget::size-allocate signal. For top-levels, though, especially the
ones using client-side decorations, you cannot use the allocation that you get
from GtkWidget because that does not include the client-side decorations. If it
did, all code running on Wayland would break, since the decorations are added
automatically by GTK+ itself.

For this reason, you need to use GtkWindow-specific API to get the size of the
window, in order to store it.

I'll make sure to change the documentation of GtkWindow.get_size() so that it
reflects reality.

> Pushing this issue on to applications by suggesting that they've been doing
> something unsupported this whole time is not a very reasonable position to
> take.

Sadly, we're in a bit of a "rock/hard place" situation, here; if we didn't do
this, we would break other, existing code, when running using client-side
decorations, both when manually added by the application developers, and when
added automatically by GTK+, for instance when running on Wayland. We attempted
that, and the resulting complexity and layering violation ended up ballooning
out of control.

In the end, we opted for asking application developers — who most likely have
to deal with ensuring their applications are already Wayland-ready — to change
their code to deal with client-side decorations.

-- 
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/20160917/4eae358f/attachment.html>