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.devel Subject: Re: master 30dbdecd4a: * src/xterm.c: Add a small writeup on input handling on X. Date: Sat, 15 Jan 2022 10:31:17 +0100 Message-ID: <658c420a-ed76-8a3d-aaf3-9ee2c0dc8f56@gmx.at> References: <164216105411.7395.2418079616938679655@vcs2.savannah.gnu.org> <20220114115054.720EBC0DA2E@vcs2.savannah.gnu.org> <87r19afs1z.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33916"; mail-complaints-to="usenet@ciao.gmane.io" To: Po Lu , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 15 10:35:04 2022 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 1n8fSg-0008a2-2P for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Jan 2022 10:35:02 +0100 Original-Received: from localhost ([::1]:49020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n8fSe-0002V7-JT for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Jan 2022 04:35:00 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46764) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8fPJ-0001Ds-UQ for emacs-devel@gnu.org; Sat, 15 Jan 2022 04:31:36 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:39307) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8fPE-0002k1-3X for emacs-devel@gnu.org; Sat, 15 Jan 2022 04:31:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1642239079; bh=APBz5net9olk42zp5WEMeLjD4Xf8DCuDPJNIsA6ccKU=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=EZG4o33oEUYIWStM/pmdeh6KopLPXBALT3x7QsDsLcOofn71vekR7lH3wNqiy1LYt Mntg4tUhql9M9n/dwDhxYGQfPYaKI6vfTuwRQ0wq5bi9sx7diH5Awo68a+gzU/0Wlb JUyCdCF23Q0ASqY4AKoFMhCkLYVkdxkkh4MhaHBc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([212.95.5.158]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MtwUm-1mL6cd2Gdg-00uJpH; Sat, 15 Jan 2022 10:31:19 +0100 In-Reply-To: <87r19afs1z.fsf@yahoo.com> Content-Language: en-US X-Provags-ID: V03:K1:kr4chUk7g3F2GXoY7goSMyyq4oVxiwKCXewROXKYbz+3t7sHhe/ a/gmeN0XXQk/szXaweKGqUtXGVmXQ5xgGGDTW8u7YDbk4HEi/U9MHoaDNYXVMMsSQooy0Ug TfQ9fOboYScbL5hyTmlt4seItY2bLQdRznpn5Pai8fKQJSTtCTiormdsWZfiioNs6vypt7m GH2nXTF4zSnuecTMkFv2A== X-UI-Out-Filterresults: notjunk:1;V03:K0:JBd7OOtJ6Es=:a6GIzwQegOqlCENBxOCsBj cOZMCv12P05VomwtQlXo4c1djDmecsRfAUIuH9bgDipMHrrXUWaH4Bg2zlsGk5JsWxdAkejqO i/ucgZipnQukM2OvA4Wc6AIzlLi2DtG09IwGeIuLMA44ybo6QI87fmD4ZAOHCYR5JAgp7x/lg Lrd9cmRHjbMKzehcYGul9v6TK49A4QHefY0+/X65r9vqHcnq7hLXW4ghvyb50nJjeUzbeEVf7 MLxWe4+U20ze6CUkd8q7j1jKFPoARwZFhy4mgGzq/0mez5DosKzNjxLGMOp0pIRhQHpsIaRRD qXDyj/VRR9WB3l4gSyFaDnO012VTuGoD7uwzE1NZSKQghjDqw03U+dJbeiqFxwrgfrnjFU63x Mod2cBkWTWBSKpB2QcZxpICEiLRmMu9rGwGKlvnjk4vPs36B4LTTfBLL1Sir2t+EA+zKwykxR FNeuYPOm2tt74thmNL3oeipUQfA/ff5BXal7vCHdkUdrJoa2/GHtOh27dwr9eQU6afrXM+Zwc pVRbDf9tfF8hxAI8Yyp7l0TpUf6BGReqKeUi81tKGkOJ8x7abK5UqI6rWyfzkhTaO9hhlb8ns SlzsVPrIxoelFzjZpdkKQafAYh3s57asaiwiWnHYBZicyVEnkB2XUqn6X6ELGlAwa+GwrZzFN CHuhx2svN5EIX4nCmitL3y4DEM6zwHucCN8u0nqkXKPwytM11QFe8dUxl7OQ5POM75gBpyWLz AUStvvttzWyK0bu32SkZUC71bRB4BQB8rSbPLb1RiCME4byzqV98PTE4LInKfOngbVCC7cgK Received-SPF: pass client-ip=212.227.17.22; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:284768 Archived-At: > Martin in particular should > write a paragraph or two about how frames are resized on X, since I > think he knows quite a bit more than I do about that part of the code. I can do that but note that most of the frame resizing code is shared among X and other backends - in particular, the necessity to call change_frame_size, set delayed_size_change there, call adjust_frame_size eventually ... While we're here - two questions related to size hints. The first concerns the x_wm_set_size_hint version in xterm.c. _My_ version of it currently starts as #ifndef USE_GTK void x_wm_set_size_hint (struct frame *f, long flags, bool user_position, bool base_size) { XSizeHints size_hints; Window window = FRAME_OUTER_WINDOW (f); if (!window) return; /* 2021 REMIX: Don't call widget_update_wm_size_hints here since on GNOME shell get_wm_shell may fail to produce the wmshell widget. As a consequence, no size hints get set before we issue our resize request, mutter (presumably) refuses to resize the outer window as requested and we end up with a wrong initial frame size. It's not clear whether other calls of update_wm_hints are affected as well but not calling widget_update_wm_size_hints here seems sufficient to fix the bug. */ /** #ifdef USE_X_TOOLKIT **/ /** if (f->output_data.x->widget) **/ /** { **/ /** widget_update_wm_size_hints (f->output_data.x->widget); **/ /** return; **/ /** } **/ /** #endif **/ /* Setting PMaxSize caused various problems. */ size_hints.flags = PResizeInc | PMinSize /* | PMaxSize */; Can you see any necessity to call widget_update_wm_size_hints here? The second question is with XSetWMSizeHints in emacsgtkfixed.c: _My_ version of its starts as /* Override the X function so we can intercept Gtk+ 3 calls. Use our values for min_width/height so that KDE don't freak out (Bug#8919), and so users can resize our frames as they wish. 2021 REMIX: But do override only if x_gtk_override_size_hints is true (the default). If x_gtk_override_size_hints is false, proceed with the original specification so shrinking frames with a specified minimum size works as intended (Bug#46963) and Emacs is always informed of the real sizes the WM reserves for its windows. We really should default x_gtk_override_size_hints to nil by default, but this can be done only after sufficient experience has been gathered, in particular on KDE. Ideally, the code below will be dropped, the sooner the better. */ void XSetWMSizeHints (Display *d, Window w, XSizeHints *hints, Atom prop) { struct x_display_info *dpyinfo = x_display_info_for_display (d); struct frame *f = x_top_window_to_frame (dpyinfo, w); long data[18]; data[0] = hints->flags; ... data[17] = hints->win_gravity; if (x_gtk_override_size_hints && hints->flags & PMinSize && f) { #ifdef HAVE_PGTK int w = f->output_data.pgtk->size_hints.min_width; int h = f->output_data.pgtk->size_hints.min_height; #else int w = f->output_data.x->size_hints.min_width; int h = f->output_data.x->size_hints.min_height; #endif data[5] = w; data[6] = h; } Do you think we could eventually drop that overriding code invented by Jan back then? BTW one of these #ifndef HAVE_PGTK #ifdef HAVE_PGTK #else #endif #endif in that code should be eliminated - but I don't know which. Thanks for your efforts, martin