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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden
> From: martin rudalics <address@hidden>
> Date: Fri, 3 Apr 2020 17:08:31 +0200
> 
>  >> 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.

OK, but that is only a convincing argument if the current emacs-27
behavior of child frames is horribly broken.  Is it? if so, can you
describe some examples of the breakage?

> 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.

The changes in mouse.el are the most troublesome from my POV, as long
as we are talking about the release branch.  They affect
mouse-resize-frame and mouse-drag-frame, two very important functions
used for all kinds of frames.  How can we be reasonably sure nothing
was broken in those two functions by these changes for frames that are
not child frames?  AFAICT, the above description doesn't attempt to
address this concern, which for me is the main one.  Can you help me
become less worried about that?

Thanks.