From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Emacs's set-frame-size can not work well with gnome-shell? Date: Fri, 3 Apr 2020 17:08:31 +0200 Message-ID: <7b79465d-ca99-8ad5-da45-16d4224d4ad7@gmx.at> References: <2056a194.3971.16f8d4dd4c5.Coremail.tumashu@163.com> <127bb534-e77c-bad0-683b-92c206feeba1@yandex.ru> <2af76486-f976-eef0-683c-45b7ea6c54eb@gmx.at> <090b65ce-f90a-c959-c72b-be73d5a2eb19@yandex.ru> <15b20ca9-b684-1ad5-3a25-822a00736c69@yandex.ru> <945fb9b8-1563-d650-ea47-4edd42d69d5f@yandex.ru> <2855252a-b9e2-47d0-6d7a-d44fa32db36c@gmx.at> <9cb2f0f2-2f9a-5122-1813-742972ee25d2@yandex.ru> <87783b28-9998-3b92-60e4-5aa328e4967a@gmx.at> <02f9fa71-308c-c613-5039-a13005ffd48f@yandex.ru> <384dd180-b194-d2b7-0a2b-2725bf2a1360@yandex.ru> <5b27dc36-df18-d188-eab3-8bf546a8c24a@gmx.at> <6668f932-62d6-6eca-190d-d270e6999d65@yandex.ru> <033361f9-eb1c-c7e6-1473-04532d0eb88e@gmx.at> <9eda9f71-2719-bb97-db4a-5b1d4a1c2087@yandex.ru> <9b0577e5-61e2-e4fa-8c95-0a08a7392e5a@gmx.at> <83tv20x1v2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="98047"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tumashu@163.com, dgutov@yandex.ru, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 03 17:12:00 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jKNzE-000PMd-1H for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 17:12:00 +0200 Original-Received: from localhost ([::1]:56838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKNzC-0006jb-Pk for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 11:11:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48543) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKNw5-0004Q6-2z for emacs-devel@gnu.org; Fri, 03 Apr 2020 11:08:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jKNw3-0005Pw-CR for emacs-devel@gnu.org; Fri, 03 Apr 2020 11:08:44 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:38509) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jKNw1-0005OM-Dl; Fri, 03 Apr 2020 11:08:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1585926512; bh=I636pD5lm0/H75/h9xkS+rXHjxsg4HISEhNu4gH5otQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ay2+dx2wFlVQ62YrLGylcLgQNvjL5+vsrM151VYFtUHC5rU2RaB9E04avzHE/077p 9hiHY4QDOsZDr+ZCXuQfrMllQSpjI1HzV04XYWgcNEYc6Dmuc2ZUcQfgsKwKn1hC2V B6BJ+sSzKsjAnsqE+/gSFJW6ovdTNFke0UfzTH0o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([46.125.249.56]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MatRZ-1imi4p1D1X-00cNAV; Fri, 03 Apr 2020 17:08:32 +0200 In-Reply-To: <83tv20x1v2.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:kmOo+by15l7v+kjdNYciUYqCODbs40v0OfKtT4hM3GwxgqfRz8S Y3kZygkQiZ6U1Tnlxx1b8TU5enPdu6prlIoVtbNkZ3AtnXDBQcekD/xPtsFwiN98ffG9EoC mjX0+6STYIqarZg7/Et4BRZdXO/upUrZ/Nl9BlkWDOtjLYIaISH2xkHcuF3kZs8NdHFB7j9 pGA4A4QqY3TkcOswtLWxw== X-UI-Out-Filterresults: notjunk:1;V03:K0:ie+M1/vdyvA=:+xPnbNalswQpL5c+qO5k26 uvl218fOsF0RAA5+aF47Pvdakq7+ReJnXXWUgyAB7FjyNGMvS/zuVn4wf1e0+PSk4GDNXtswb 4AoB0MEl4pIQRcFlc5jQz0KoC/yATqRLM4CZQjyPXmG4iwlVkyHZsn0rkifIJ7Y+O9e6K10Q7 OYUDiSnE33qyEWM97s4Bk84jp0nMIjVO13sAYCwFzoCa412ynGqtmInpF8PC90/i1y7rNoZWB 6CEraJpMKAJ9Z6zHsh6MokQeuHJt/nNDEkhBFupd8S2Z9Ik1xDAmWlHWaVSuHv/vd8CEj7SAO KT4VCOEf8tPDKw/rL8itlxqPL7na6oZ7wftPQ+8DEeasvj0+EX+L/i36pmrK58914D/TRKVKA nYlSBzQioq7ERZ2IpG4+TKUlLLTCUZPZCwV/lZtB2t2yyaBraoUkaVrLs+Bobnxbz9Zci9oMI nEFKX+sV+KffNrFimbCMqoTRllg9RLhJHlpREZSA0gNb+4peqkP+vEOw1mqzeu5eCRzIc067S x7WiV9gBKqgfAmrDpH3BdPZxtxHhBFOfMcT1fyKJv/RzDfVJ3LPiiVBL73qDfSEoFEBNrlIqx zEHS3RhyR28kQ56LcHITbKRfb5TLErXYecdbC4kalULpbZcbBdBhhULK0Gf0JE91KtfPpDtol rKGWvBxsSLRXHOnD8DvRbXBlO6hqBrrJ73v9th8H76pLGgCGgHKPxR7dVmkqZ1Fl2TIsk7YE0 haTgbo7sfpxwmwos35GX/wzD4UkctP3eSbIv6CZ1KETufLwBPyN/avR1W38qh+pjdy3N2BzJ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246332 Archived-At: >> 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