GNOME Bugzilla – Bug 780810
GtkWindow size-allocate width and height are way too big in Wayland
Last modified: 2017-04-24 18:41:59 UTC
I'm writing a neovim remote-ui using GtkTextView. I'd like to be able to resize the window to fit the TextView in case the embedded nvim requests a resize, or to keep the same number of text columns and lines if the user changes the font on the fly. From reading #771112 I realise now I was trying to do this the wrong way, but that's beside the point, because I found that the width and height in the window's size-allocate signal are even more unreliable than expected. For example, when the TextWidget's allocation is 480x390 the window's allocation is 532x473. There are no other widgets or padding between the TextView and the window; in X11 the allocation values are the same for both. Even if the window was CSD (which it isn't), and the allocation included the shadow effect, that's still a big discrepancy, so I feel like there's something wrong that warrants investigation rather than just ignoring it because we're not supposed to use GtkWindow::size_allocate any more.
> Even if the window was CSD (which it isn't) You're on wayland, so yes, it is using CSD. > in X11 the allocation values are the same for both. What if you use CSD on x11? Same difference? In any case, I fail to see why you or anyone else would care what the values passed to size-allocate for the toplevel are.
(In reply to Timm Bäder from comment #1) > You're on wayland, so yes, it is using CSD. OK, I didn't realise Wayland forced CSD on. > > in X11 the allocation values are the same for both. > > What if you use CSD on x11? Same difference? I don't know how to force CSD in X11, other than use GtkBuilder definitions, which isn't a good fit for my use case. > In any case, I fail to see why you or anyone else would care what the values > passed to size-allocate for the toplevel are. Like I said, I realise I shouldn't care, but the numbers are so far wrong, even taking CSD into account, don't you think that might be indicative of a bug somewhere? Perhaps related to <https://bugzilla.redhat.com/show_bug.cgi?id=1207943>.
I think running with GTK_CSD=1 forces csd even on x11. I don't think that's wrong it's the window's border plus shadows, twice. And vertically it's that plus the allocation of the titlebar. Checking a CSD demo under wayland, I see the titlebar allocated at x = 26 (26 * 2 = 52, the horizontal difference in your example) and at y = 23. I guess Adwaita uses difference shadow radii here. But the titlebar has an allocated height of 37 px and 23 * 2 + 37 = 83, the vertical difference in the example you provided.
I suppose the area influenced by the shadows is much more extensive than what can be seen with the naked eye then. To me they look as if they fade to nothing within the space of 2 character widths, and the same app reports each character as only 6 pixels wide (logical pixels; this is actually a hidpi screen, otherwise such a small font would probably be quite ugly).
its called 'invisible borders' - we have a larger area outside the visible shadow where you can click to resize.
I know about the invisible borders (FWIW I appreciate that feature), but I can see their limits from the pointer shape (and confirm by trying to drag a border), and for me they don't extend beyond where the shadow seems to become invisible.