Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

>> OK.  Eli, I would like to install the attached patch for Emacs 27.
>
> I'm sorry, I'm really at a loss regarding this jumbo changeset.  Why
> exactly does it have to be in Emacs 27?  Child frames were introduced
> in Emacs 26, not Emacs 27.

Apparently, child frames are in wider use only since last year.

>> All changes affect the resizing and moving of child frames only,
>> normal frames are not affected.
>
> You say that, and I believe you actually meant that, but the code
> changes many functions that do affect normal frames, AFAICT.  I don't
> see how can we be sure normal frames are not affected.  If you have a
> way of showing that convincingly, I'm all ears.

First of all let me note that none of the problems this patch tries to
solve cannot be observed on Windows.  The Windows API wrt child windows
is to my knowledge correctly implemented by the underlying routines.  As
a matter of fact, most problems my patch tries to fix have been observed
with GTK3 builds of Emacs running on the GNOME shell desktop under the
mutter window manager only.

Now about the individual parts of the patch:

(1) The behavior I try to fix in mouse.el has AFAICT been observed by me
only.  While the patch is not restricted to child frames the
functionality it fixes is not useful for non-child frames: All window
mangers I am aware of allow to move a non-child frame by dragging its
title area with the mouse and allow to resize a non-child frame by
dragging its external borders.  Windows provides the same functionality
for child frames.

However, practically all X windows managers I'm aware of neither allow
to put a title bar on a child frame nor do they draw a border on them.
Hence, in order to provide the same functionality for child frames they
are automatically given by Windows, I had to implement that
functionality on GNU/Linux manually.  And while I did that, I made the
incorrect assumption that move and resize events would be reported in
the order they were issued.  That assumption was unfortunately wrong
and caused, for example, a child frame's right edge to move too when
dragging its left edge in order to shrink or enlarge that frame
horizontally.  All changes in mouse.el are there to fix that behavior.

(2) The change in gtkutil.c's xg_frame_set_char_size is clearly for
child frames only due to the guard

  else if (FRAME_PARENT_FRAME (f) && FRAME_VISIBLE_P (f)
           && EQ (x_gtk_resize_child_frames, Qhide))

and the fact that was_visible can be set only within the ensuing clause.

(3) The change in xfns.c's x_set_parent_frame is clearly for child
frames only.  The change in Fx_create_frame is separately guarded by a
(!NILP (parent_frame)).

(4) Adding x_gtk_resize_child_frames to xterm.c cannot affect
non-child-frames.  Its use is restricted to (2) and both instances of
(3).

(5) The change in x_set_offset of xterm.c does affect child frames only
in the sense that some part of x_set_offset is not run for child frames
via

  if (!FRAME_PARENT_FRAME (f))

The changes (2)-(4) are an attempt to fix the resizing of child frames
for GTK3 builds on mutter.  Users are supposed to put them into effect
there and only there by setting 'x-gtk-resize-child-frames' to non-nil.
Users of child frames on other systems should not notice them.

(5) affects all child frames under X and is needed in order to omit the
(IMHO useless) step that tries to reposition a frame when Emacs believes
that it detected that the frame was incorrectly positioned.  One reason
for this is that some newer window managers make the external border of
a frame invisible, position the visible part of the frame as Emacs
requested but report the new position of the frame as the one where the
invisible border starts.  For example, when the visible part of the
frame starts at (0, 0) the reported position has negative values
(Bug#38452).  IIRC Windows 10 does something similar.  Unfortunately, in
its X code, Emacs induces a 0.5 secs wait whenever it believes to have
detected such incorrect positioning which makes dragging a child frame
with the mouse unacceptably slow.

So the only thing that really affects non-child frames as well is the
earlier mentioned addition of 'x-gtk-debug'.  In fact, that addition
does not fix anything but might be useful when advising a user how to
debug a problem with GTK3.

martin