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, 21 Feb 2020 17:08:04 +0100 Message-ID: References: <2056a194.3971.16f8d4dd4c5.Coremail.tumashu@163.com> <414ade05-1ae6-75c2-9af1-e1eee42799a0@yandex.ru> <44010781-43f0-3bc3-06ed-475c526dee36@gmx.at> <70813591-8c24-cb30-8ecf-0c413a51f472@gmx.at> <81215100-3476-9d2c-f535-f57fbd18fd8b@yandex.ru> <8a485c09-535a-97e6-9817-31e6d2f93adb@gmx.at> <0734f22f-9237-d46a-27d5-016444f48d70@gmx.at> <5e28c37f-95a9-a5ae-d73c-b5bb769154c0@yandex.ru> <4c0993c7-0583-8573-60c5-ab0a92121fd3@gmx.at> <4b114f01-d8d9-2c33-6312-1e2e60a5d462@yandex.ru> <127bb534-e77c-bad0-683b-92c206feeba1@yandex.ru> <2af76486-f976-eef0-683c-45b7ea6c54eb@gmx.at> <142acada-f0d1-edb2-983b-c8f2da559ca8@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------F0262BA5ED58AC40C67C96EA" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="36053"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" To: Dmitry Gutov , tumashu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 21 17:11:37 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 1j5Ats-0009IZ-TF for ged-emacs-devel@m.gmane-mx.org; Fri, 21 Feb 2020 17:11:37 +0100 Original-Received: from localhost ([::1]:60586 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5Atr-0004Wu-Ob for ged-emacs-devel@m.gmane-mx.org; Fri, 21 Feb 2020 11:11:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44259) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5Aqn-00024Y-1y for emacs-devel@gnu.org; Fri, 21 Feb 2020 11:08:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j5Aql-0005wW-1C for emacs-devel@gnu.org; Fri, 21 Feb 2020 11:08:24 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:38457) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j5Aqk-0005uP-JM for emacs-devel@gnu.org; Fri, 21 Feb 2020 11:08:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1582301286; bh=5c9ElzLdbuKnhENssMCV2rmYe0uVc5NyL1CEQE6dlQ8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=OXlrMDXyN3Xs3t3AB7u7MK14CQrBlz1ho9HtYRz9+sPEVW3uwtCa7SgF1HkZFO0nC esW6hTCtAOht3gnKidj/Mh/TW4AzCNJa0u9Qe4so66SvNguZE1Lm0QziAMJtx7NLvg tLhvGzFCyoZapiX/WXg6aC7WW4iKhpW4TZE7IwZc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.192]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1ML9yS-1ioCBz3Ob4-00IHfK; Fri, 21 Feb 2020 17:08:05 +0100 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:xSGAbdapAvR+3zhU4iKlrn1j+Bi2c0ZjmW9GWeyyMO/n4ehTc4l kRRgGWIf58XoRKh+vJxOA51nEijKcb2lCBEqjwK4kcz4vYwIbwDf+g33Dk7+7rAUSHqN6Sf bNbW+5iefzDLi3IoClLiny4x4PynO8+e9edQovCbnPz0kSNEnGFbvRbI8CuATmwSX8nvybT U/DxOjWRctckdBE9sPwAw== X-UI-Out-Filterresults: notjunk:1;V03:K0:x/koxLo+uc8=:ccItXpJCF9BQwNgACRL+3A Lk179oTuAQd+NtXUU41L8uqVzHM0VOYhgSNM2I9AxSXmXSfygHN8aTOKF7PnbBgWLf4DM4Pjr YPVjM75g6uVcUjJfder1VbhPnF0gTbOT+RYpbDjd9EK1xc1xLlhmGyx1IZGC2SHf5p9gogBd0 JfBrjPqGqWkWLXRy9gwQAbLcvI/wbcfUD3uMHbxCNaMzDyWOIdPbQwjLOrWK0+Ft5vRINcClB R8CkojomZFrrntoVaWgi/3DM6M0o9EBeFkX+Hm9s5cWj3X2bzUSrOANGvyuj3tateTX5NOiW7 kCtvRrMD5bc5EubMB0v8RZbDX7U1IMMkxajq94BFqvn/UDBvnaoTwY0ONgIanPDjgmISieokp 4t0c2IrAphdTvRwE/jMmADQNwQrUFMk7J2cWbnLEOOXV3kdv26FBJhok2YrKmzybbQ0nXpAfl E9fgGP1wRM8Q2pVaVq+tul8azQ6oyS9DB7coJH2qqliLWMpkjsuWZOqXHMwRw6MDV8QTAB7ZM YcgthcKgj4JEtcKbPZVaZd05CkkRrOxrwzdXLvtF+w7QkhycbF98jD6XqmgKB1P+Qv6Rquti2 ck7l+JOgj8oaj6RMKsl8siJgc691az7due/KFrOs2fwPI2LoKJsEZZlJFytn4Nc8PtCbCHXvr VgGPgjeFvGJxDLE+/NNoztZvFYogz1iP6uzO1DcUBoptYF+oDiUx6mNIwgOW4lMcWm0I8PuA0 Yw69uapGNuhXptuXusBbSbs9CYqINIuOl8LxqxrFvGTOvGi1j5xYqQYJfNrgH/c88MvvoOqg 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:245016 Archived-At: This is a multi-part message in MIME format. --------------F0262BA5ED58AC40C67C96EA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit >>> Did you set 'x-resize-child-frame-special' to t? >> >> I... no. I only changed the value of this variable (locally or globally) after the frame was created. > > Sorry, the email got sent too fast. > > Resizing indeed works if this variable is set to t before the frame is > created. My bad. I should have explained it better. > One problem is that the initial width and height are 2x the specified > (probably scaling at fault). With the patch applied and 'x-resize-child-frame-special' non-nil 'x-create-frame' asks for an initial frame size of 1000x1000 pixels if (FRAME_PARENT_FRAME (f) && x_resize_child_frame_special) adjust_frame_size (f, 1000, 1000, 0, true, Qx_create_frame_2); So what you see could be the 1000 (2000 scaled?) pixels from that call. You could try with other values instead of 1000 so we can tell whether that call has any visible impact. It's possible that the WM rejects too large values, for example, because they would exceed the initial size of the parent frame (insanely large values can make Emacs even crash here). And always keep in mind that all this is a crazy hack that tries to second-guess what the WM (or GTK) might do. I've nowhere in their code seen the slightest evidence for such behavior. > Otherwise, it seems to work OK is the test scenario. Not so ideal in > "production": it seems company-posframe still fails to change the > width (!) when height is kept unchanged. And when that happens, the > expected extra area (when we're enlarging the frame, but seemingly > fail) is apparently where Emacs and the WM disagree (clicks don't do > through). Did you use 'set-frame-width' to change it? Does it also fail to shrink the width or only to enlarge it? In either case I attach a patch that now tries to make the second adjust_frame_size call apply the initially requested sizes but I'm afraid that it will not produce anything useful. martin --------------F0262BA5ED58AC40C67C96EA Content-Type: text/x-patch; name="x-resize-child-frame-special.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x-resize-child-frame-special.diff" diff --git a/src/gtkutil.c b/src/gtkutil.c index 6308c38f16..a77810141a 100644 =2D-- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -997,12 +997,13 @@ xg_frame_set_char_size (struct frame *f, int width, = int height) } else { + GdkWindow *gwin =3D gtk_widget_get_window (FRAME_GTK_OUTER_WIDGET (= f)); + frame_size_history_add (f, Qxg_frame_set_char_size_3, width, height, list2i (totalwidth, totalheight)); - gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), - totalwidth, totalheight); + gdk_window_resize (gwin, (gint)totalwidth, (gint)totalheight); fullscreen =3D Qnil; } diff --git a/src/xfns.c b/src/xfns.c index 276ea1c393..ea6c6902aa 100644 =2D-- a/src/xfns.c +++ b/src/xfns.c @@ -4125,6 +4125,13 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create= _frame, x_wm_set_size_hint (f, window_prompting, false); unblock_input (); + if (FRAME_PARENT_FRAME (f) && x_resize_child_frame_special) + { + adjust_frame_size (f, 1000, 1000, 0, true, Qx_create_frame_2); + SET_FRAME_WIDTH (f, x_width); + SET_FRAME_HEIGHT (f, x_height); + } + adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f), 0, true, Qx_create_frame_2); diff --git a/src/xterm.c b/src/xterm.c index 21d99f0c7b..84b154f8fc 100644 =2D-- a/src/xterm.c +++ b/src/xterm.c @@ -8953,6 +8953,23 @@ handle_one_xevent (struct x_display_info *dpyinfo, #ifdef USE_CAIRO x_cr_update_surface_desired_size (f, configureEvent.xconfigure.width, configureEvent.xconfigure.height); +#endif + f =3D 0; + } + else if (f && FRAME_PARENT_FRAME (f) + && x_resize_child_frame_special + && (configureEvent.xconfigure.width !=3D FRAME_PIXEL_WIDTH (f) + || configureEvent.xconfigure.height !=3D FRAME_PIXEL_HEIGHT (f))) + { + block_input (); + if (FRAME_X_DOUBLE_BUFFERED_P (f)) + font_drop_xrender_surfaces (f); + unblock_input (); + xg_frame_resized (f, configureEvent.xconfigure.width, + configureEvent.xconfigure.height); +#ifdef USE_CAIRO + x_cr_update_surface_desired_size (f, configureEvent.xconfigure.width, + configureEvent.xconfigure.height); #endif f =3D 0; } @@ -13747,4 +13764,10 @@ syms_of_xterm (void) consuming frame position adjustments. In newer versions of GTK, Emacs always uses gtk_window_move and ignores the value of this variable. */); x_gtk_use_window_move =3D true; + + DEFVAR_BOOL ("x-resize-child-frame-special", x_resize_child_frame_speci= al, + doc: /* Non-nil means treat child frames specially during resizing. +Set this if and only if your window manager refuses to resize child +frames as expected. */); + x_resize_child_frame_special =3D false; } --------------F0262BA5ED58AC40C67C96EA--