From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#46827: Broken initial size of GTK3 frame Date: Wed, 3 Mar 2021 09:48:16 +0100 Message-ID: <83a5e0e7-a55d-48bf-00f6-942d6c6c3be5@gmx.at> References: <6caa020a-084c-e3f2-7a34-262f7127b21b@gmx.at> <87eegz41ui.fsf@gmail.com> <875z2b3srx.fsf@gmail.com> <87ft1fyo88.fsf@gmail.com> <8a346498-e7e3-ca92-e518-86f6fc2c37b7@gmx.at> <87y2f6spgm.fsf@gmail.com> <87v9aaslh9.fsf@gmx.net> <689ba08c-639f-af40-5c30-95dcceac552f@gmx.at> <359cec57-48d3-dc97-df0f-a778a0786001@gmx.at> <83zgzl63y0.fsf@gnu.org> <83tupt5x95.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------62F7EF5189DC7DB40FC0218B" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1095"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46827@debbugs.gnu.org, rpluim@gmail.com, stephen.berman@gmx.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 03 09:49:24 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1lHNC8-0000Cx-Lt for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 09:49:24 +0100 Original-Received: from localhost ([::1]:55060 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHNC7-0003bR-OE for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 03:49:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44354) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHNBm-0003Zk-J0 for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 03:49:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43547) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHNBm-0007cq-6w for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 03:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lHNBm-0007Ua-41 for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 03:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Mar 2021 08:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46827 X-GNU-PR-Package: emacs Original-Received: via spool by 46827-submit@debbugs.gnu.org id=B46827.161476130728760 (code B ref 46827); Wed, 03 Mar 2021 08:49:02 +0000 Original-Received: (at 46827) by debbugs.gnu.org; 3 Mar 2021 08:48:27 +0000 Original-Received: from localhost ([127.0.0.1]:55093 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHNBD-0007To-Ky for submit@debbugs.gnu.org; Wed, 03 Mar 2021 03:48:27 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:59485) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHNB9-0007TZ-T1 for 46827@debbugs.gnu.org; Wed, 03 Mar 2021 03:48:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1614761297; bh=WqR9H6k7403MGeZm9YVPUVWxXxfavCbwVpAMDoUePWc=; h=X-UI-Sender-Class:From:Subject:To:Cc:References:Date:In-Reply-To; b=BjQ1Vom/NjYC+TsWKGM5ow/VY18PPJkLnV1F0Vp+yJcEHfwGQ88ds40JfsyJZygam biDUx7Beq5x88PuW9ulcswIQkhuop6OmlRZon+U0A6V35tlYBUzLHyvStZQotyefh1 M45nes9eo9dNDmGmABe6QlunupIMo6stLWXKJhW8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.7.233]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MIwzA-1lW98t28gE-00KPcf; Wed, 03 Mar 2021 09:48:17 +0100 In-Reply-To: <83tupt5x95.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:BbK+keDRi74FtsBQ4wFRVAGKt0ChELa4i0Me23ZV5RLEni+7B0G 0fv6YK/P4604D2poNVkJ1TKBGXZfPWWbyQNi5SLeMmmKVOnmttO1FrlOB86Jw+/9ld/2jja aPvALyEoH/D6XdxdIEIcXGPMCTf4g+exQf2KLJvNPmZLWlKuIbpoQtOEDEZZaDDMTNXfSyJ 5+K76GwSS1Jj0unSbBuJA== X-UI-Out-Filterresults: notjunk:1;V03:K0:CMHoHDbNYTo=:S/iMPiOCUTGMZM3tjhrI5Z f8IvCv7k6Pol8Qx9KvCYtOhoY7qIGBW7lDoJWrMuU+o6Zssb3eTkGS1/upvrejoyMr5aIkduj +9WvDxsZ+xa0abWhGLL7R35UN0Hi27f+tJL96oO/mtdLCER1CYTYnp0rHJiIXVgyOAPzXaUus CHBfxAtfCFbcBp4uXystix3+axyHyqRtKyfX1wXwVuZBfah6Xc3rF7KP+tiuF5TI0eqfP3jbC MYl8EMV/HGC6Rkh/oeme5z6YEle2XGuih4PvbtnoYScnDb/F1BCflzPvRnME9Yn1XzY4og2+K l5InqxWiB+HO7MnfjFcE05qq/FWh1nloH69waaNtPbK4iiLL0MXQlb6dznUg4BcqrrCP0xbJJ OLnoX026b5Uvq56rgnB/7GykcObizjTFwy8/kw/2YGokvvoY38jE2bZ98kkk1AjWUkl2ZHqkN G842BUFakdIEaoEk46PKFWM22ZTt/BNxxpfBU8PHWZjItwacopbTpOiQEwmZ/BOu2q+ki2zh9 05bAwyifecbYiVMe3LxMYhFXmhg1aiK7rIIKUrU6ho/sc4qGLYwzc+LDiLNgI++oCec5VFdL5 a0FnxkVShf+oLl2hYwTHKFcVqc1nsfuhAGe73DsIcn5yUHiqHpgPAJAiCLbezr20hVoc9aMiZ arvkhQJfzboZlZY/AsGkUGdVki5uHVYem+MjMPsQYodXV0BFMD2MnzNDM9Bf6WOla6m5AlFQN 3cGDwDJVFPe/PDGe455Lqc/4TohZ5EDDqauSj5KFFk2QqRUv7+Jq9T0MNBTC6jnC4QmjCfdU X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:201263 Archived-At: This is a multi-part message in MIME format. --------------62F7EF5189DC7DB40FC0218B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit > Thanks, but is there any reason to remove the call before updating the > tool bar? You see, I believe one of the reasons for the need to > clear_garbaged_frames is that call you suggest to remove. Why not > leave it there, and _add_ one more call after prepare_menu_bars (and > perhaps condition it on the same condition as prepare_menu_bars)? We can obviously do that (see attached patch). But is there any reason we cannot run the do_pending_window_change (true); clear_garbaged_frames (); _after_ the prepare_menu_bars (); do_pending_window_change (true); block? In either case, the more I look into this, the more things confuse me. For example, why does if (!must_finish) { do_pending_window_change (true); /* If selected_window changed, redisplay again. */ if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw) goto retry; not check for windows_or_buffers_changed too just as we do after the third do_pending_window_change call? But then I don't understand why we check for windows_or_buffers_changed at all. adjust_frame_size doesn't set that IIUC but it does garbage the frame - why don't we check that in redisplay_internal? >> While frame resizing can make the >> selected window small, it will neither remove nor change it. > > Never-ever? Never-ever. Fdelete_window_internal, Fdelete_other_windows_internal and Fset_window_configuration are the only functions allowed to delete windows. run_window_change_functions could delete the selected window so we probably should do the w == sw check after that now. martin --------------62F7EF5189DC7DB40FC0218B Content-Type: text/x-patch; name="xdisp.c.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xdisp.c.diff" diff --git a/src/xdisp.c b/src/xdisp.c index cc0a689ba3..78f25af991 100644 =2D-- a/src/xdisp.c +++ b/src/xdisp.c @@ -15658,7 +15658,13 @@ redisplay_internal (void) /* Build menubar and tool-bar items. */ if (NILP (Vmemory_full)) - prepare_menu_bars (); + { + prepare_menu_bars (); + + /* Once more taking into account the new tool bar height + (Bug#46827). */ + do_pending_window_change (true); + } /* do_pending_window_change could change the selected_window due to frame resizing which makes the selected window too small. --------------62F7EF5189DC7DB40FC0218B--