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

Previous Next

To reply to this bug, email your comments to 40817 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Trevor Spiteri <tspiteri <at> ieee.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.91; setting frame parameter '(left - 0) leaves gap to the right
 under GTK
Date: Fri, 24 Apr 2020 15:36:50 +0200

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

Message #8 received at 40817 <at> debbugs.gnu.org (full text, mbox):

From: Trevor Spiteri <tspiteri <at> ieee.org>
To: 40817 <at> debbugs.gnu.org
Subject: Re: bug#40817: Acknowledgement (27.0.91; setting frame parameter
 '(left - 0) leaves gap to the right under GTK)
Date: Fri, 24 Apr 2020 16:44:00 +0200

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?

Message #11 received at 40817 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Trevor Spiteri <tspiteri <at> ieee.org>, 40817 <at> debbugs.gnu.org
Subject: Re: bug#40817: 27.0.91; setting frame parameter '(left - 0) leaves
 gap to the right under GTK
Date: Fri, 24 Apr 2020 19:55:04 +0200

> 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

Message #16 received at 40817 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Trevor Spiteri <tspiteri <at> ieee.org>, 40817 <at> debbugs.gnu.org
Subject: Re: bug#40817: 27.0.91; setting frame parameter '(left - 0) leaves
 gap to the right under GTK
Date: Wed, 29 Apr 2020 16:12:07 +0200

>>>>> On Fri, 24 Apr 2020 19:55:04 +0200, martin rudalics <rudalics <at> 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

Message #19 received at 40817 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Trevor Spiteri <tspiteri <at> ieee.org>, 40817 <at> debbugs.gnu.org
Subject: Re: bug#40817: 27.0.91; setting frame parameter '(left - 0) leaves
 gap to the right under GTK
Date: Wed, 29 Apr 2020 17:03:18 +0200

> 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

Message #22 received at 40817 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Trevor Spiteri <tspiteri <at> ieee.org>, 40817 <at> debbugs.gnu.org
Subject: Re: bug#40817: 27.0.91; setting frame parameter '(left - 0) leaves
 gap to the right under GTK
Date: Wed, 29 Apr 2020 18:51:52 +0200

>>>>> On Wed, 29 Apr 2020 17:03:18 +0200, martin rudalics <rudalics <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.