bug#40817: 27.0.91; setting frame parameter '(left - 0) leaves gap to the right under GTK

[martin rudalics <rudalics@gmx.at>]

 > If I evaluate this when using GTK
 >
 > (modify-frame-parameters nil '((left - 0)))
 >
 > there is a gap to the right of the frame equal to the total size of the
 > horizontal window decorations.
 >
 > I tried to debug this and this is what I found. (This is what I think
 > causes the bug.)
 >
 > This calls xterm.c:x_set_offset with f->left_pos = 0 and
 > f->size_hint_flags = XNegative.
 >
 > This in turn calls xterm.c:x_calc_absolute_position. Here, the edges are
 > found using Fx_frame_edges ( frame, Qouter_edges), and the width of the
 > frame *with* decorations is thus used. Then, f->left_pos is set to
 > display_pixel_width - width_including_decorations + 0.
 >
 > Back in x_set_offset, x_gtk_use_window_move is used to move the window;
 > there is a function call to
 >
 > gtk_window_move (..., f->leftpos / scale, ...)
 >
 > However, gtk_window_move seems to be correcting for window decorations
 > itself, so that if we are to use gtk_window_move,
 > x_calc_absolute_position should have used the width *without* window
 > decorations.
 >
 > I can reproduce this in Emacs 26, so it is not an Emacs 27 regression.

 > Thinking about this a bit more, it is not clear to me what the frame
 > decorations actually are: are they a solid outside border, or a shadow
 > added by the window manager, or both? And I'm thinking the issue I'm
 > seeing is caused by the shadow under GNOME, but if there is a solid
 > border, the current behaviour would be correct maybe?

I suppose this happens with GNOME shell and the mutter window manager.

Most window managers draw a solid outer border which can be turned off
optionally.  But mutter "draws" an invisible outer border (IIRC Windows
10 does the same) which causes all sorts of problems.  For example, if
you ask mutter to position a frame at (0, 0) of your display, it will
apparently put it there but report a position of (-10, -8) which is
where the invisible borders start (compare Bug#38452).

Such invisible borders make calculated frame positioning difficult.  For
example, positioning two frames side by side to fill the whole display
becomes a real pain.  Note that Emacs also has a method to "correct"
such incorrect positioning but that works for Lucid and Motif only.  And
it's completely useless for invisible borders because it would put a
frame Emacs wants to position at (0, 0) at (10, 8) which is probably not
what the user wants.

Your scenario demonstrates that such invisible borders make putting a
frame at the right or bottom edge of the display hard as well.

martin