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

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

[Trevor Spiteri]

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.



In GNU Emacs 27.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.13, cairo version 1.16.0)
of 2020-04-23 built on desktop
Repository revision: ba6104d1e8db4e8db2f12acaebf092ef579c6632
Repository branch: emacs-27

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

[Trevor Spiteri]

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?

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

[martin rudalics]

 > 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

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

[Robert Pluim]

>>>>> On Fri, 24 Apr 2020 19:55:04 +0200, martin rudalics <rudalics@gmx.at> said:

    >> If I evaluate this when using GTK
    >> 
    >> (modify-frame-parameters nil '((left - 0)))
    >> 
    martin> I suppose this happens with GNOME shell and the mutter window manager.

I see this with the GNOME shell on Ubuntu 20.04 (not sure if itʼs
using mutter, how does one check that?).

However, the good news is that the behaviour is correct using the
pgtk build, including '((top - 0)).

Robert

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

[martin rudalics]

 > I see this with the GNOME shell on Ubuntu 20.04 (not sure if itʼs
 > using mutter, how does one check that?).

With the task manager.  With wmctrl it identifies itself as GNOME shell.

 > However, the good news is that the behaviour is correct using the
 > pgtk build, including '((top - 0)).

Good to hear.  I haven't had time to look into this so far but I always
hoped that a pure GTK build would solve this and maybe some of our other
GTK issues.  It would be interesting to know whether and how the
arguments of

	gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
			 f->left_pos / scale, f->top_pos / scale);
in xterm.c and

     gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
		     f->left_pos, f->top_pos);

in pgtkterm.c differ.  BTW, did you test this with X11 or Wayland?

martin

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

[Robert Pluim]

>>>>> On Wed, 29 Apr 2020 17:03:18 +0200, martin rudalics <rudalics@gmx.at> said:

    >> I see this with the GNOME shell on Ubuntu 20.04 (not sure if itʼs
    >> using mutter, how does one check that?).

    martin> With the task manager.  With wmctrl it identifies itself as GNOME shell.

Hmm, 'mutter' doesnʼt appear there, but
/etc/alternatives/x-window-manager points at mutter (and it behaves
consistently with the description of this bug).

    >> However, the good news is that the behaviour is correct using the
    >> pgtk build, including '((top - 0)).

    martin> Good to hear.  I haven't had time to look into this so far but I always
    martin> hoped that a pure GTK build would solve this and maybe some of our other
    martin> GTK issues.  It would be interesting to know whether and how the
    martin> arguments of

And I spoke too soon: the pgtk build moves the frame to the right
edge, but also to the top.

    martin> 	gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
    f-> left_pos / scale, f->top_pos / scale);
    martin> in xterm.c and

    martin>     gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
    f-> left_pos, f->top_pos);

    martin> in pgtkterm.c differ.  BTW, did you test this with X11 or Wayland?

left_pos is scaled (in this case / 2), and top_pos is 0, because
thatʼs what itʼs set to in the frame. Thatʼs a separate bug though,
looks like thereʼs a missing initialization somewhere for the top_pos
and left_pos parameters.

Robert