From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Abysmal state of GTK build Date: Sun, 21 Aug 2022 21:59:23 +0800 Message-ID: <87czctk890.fsf@yahoo.com> References: <87ilmlluxq.fsf.ref@yahoo.com> <87ilmlluxq.fsf@yahoo.com> <87h725olz1.fsf@gnus.org> <87zgfxn6lt.fsf@gnus.org> <87tu65k9ec.fsf@yahoo.com> <87r119lnsd.fsf@gnus.org> <87mtbxlnf1.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30343"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 21 16:00:36 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 1oPlVC-0007kd-UO for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Aug 2022 16:00:35 +0200 Original-Received: from localhost ([::1]:34388 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oPlVB-00036h-Uk for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Aug 2022 10:00:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43908) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPlUK-0002Q3-9m for emacs-devel@gnu.org; Sun, 21 Aug 2022 09:59:40 -0400 Original-Received: from sonic308-56.consmr.mail.ne1.yahoo.com ([66.163.187.31]:41767) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oPlUI-0005IJ-0o for emacs-devel@gnu.org; Sun, 21 Aug 2022 09:59:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1661090375; bh=BEKSGD2gnvZqq0S2UIEfFu5TGU73NYNexMGWUDWF5IQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=D4icPfUKDzDEqYefxFyyZCdX/QPfs9I2VrInWdv04VhGYq88Gx1HO2D1+Mq1fBWzk2ryXD3Q8IH71kWtND90hfpguwXL2esiGsvu0eavj95aJF0Oo3erSivNExkOE5lglsEoLl8pREPfzOY82KfieueEQTJkYJJmwBQxT/H+AEtfENdNWJVP8JHRVv1KeiEh4F/ilnF87sjCDJ8hdL08TIPBBZXmngeBeewVWC7VzzY4l3atDwzxualT3tU46wp0XMMSMfxwHuUHK5hjNnaCt2c545zvlrtGGNhNwEQCLxHRY3MwTrcg2x80l06JjCB3jKC86kDAx/Gp3eFXoU+8Ng== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1661090375; bh=ByK90Xst9MJ76Ch1aSHoGFwK0wnpFmXd6a2pyjV407f=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=hh3lrfkYoUQAymHAHnvDwjphf5HqbxOzl4EraOeDp+ZdL/Ro8yCUncMSbw0UuicFMq8FnwAzggP2V9rY18BM6gK5qKF4qRT759jRA6QlCfvSroIKhAas6agl2ZKTjzMtgkViA71HnZNZxUSGGAXWnVilPQJBwiuR/WZFj8d5kovnL15yFpYfTvDkrFSUpu0FTswY8Pqi0Wap9TB4k4QT4lF56fRuEYsDpOvbF6qWlWRnMWypPE/PnkDezE3aNBydNDqsHM3U3oplFqGayfivY+tPfouzxrqNO1D5dnepAhTR+RIKQohctnbMKi1L/pYfDgijSa4zggayve9/zjmE7g== X-YMail-OSG: zf3SJpkVM1lQJoxrxjOa8_lAcG96c_1gXSfILlE6u9J.dUVWHy57PkpW_Lk2W5E u8CqvCUXfJn6vibpWDIvS5O4ZpBZHXOvWyXgB7YOAcXyYUiYdjAIYbM2k1ZGL.zljpY7mjCqVJa1 7OtARPZZbhpFhZyWRDfJMSvgHl0JYGtEaUOjFUntsvjRQlvnWYpFGJi2ML7tEpB2.fZhOlfZ5.Lm DuZ4X6qmVGmnKr.aZLXaKutP3wZSJQoCC2CXSfPRTXQSkVibk0hyU2psYhUdyiplmGnWDiQwxlBh 97ZOZq3lCfYT4KoiX6fLhz80EHPG0RKYJvBQWVYjpNfa4iT3MqgHiYOg9TBCIomw11.3_6HZseq3 oDWSB08NRqHBh3vTZORotRlKRv8rFJ99s.PUkL0Jnspmtfwsrg7AFhxiCaGgVMx2I2IJFJZubzQw 2Rz2KEGUYhPhp_UEl7Q9ZlKsbjVEBozGlDzQeyI1RSHGk0WLkfw3zV4qTvdpqe56OdH95aVBQz5q LRX7Pha1AjPHZeRwrkegux265gwB16zMJQc0JGe5ybQNeUIZ78FRmSq44k.lDoZDi6jDFhO3hyMn qcjkpdjBck__LauHeoSleuhi9DJyEv39OGbu1E0.NITmBHUc.KG.BTtwD8m8s96rNSOYb.P55JvT OSeIXlgWSgaXYRfqZYYSF6sr7M61UUc9DSQ_zTwmx7D1JihWPZ.6s63JlC.0ihb5a7MqjJHd7ALO sXJKci.gc8tlHdQREy3NYXoYMfPFicmaUNQ17aUNmvjOjpzrCRgS1EsUxRsu1pOSzYirneCJRHUC K069Ay4Dlg5gSwNeK2QGzHVLV3CxopGHJnR6rstxfh X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Sun, 21 Aug 2022 13:59:35 +0000 Original-Received: by hermes--canary-production-sg3-6f58cd9b5-vlgxl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 670b8089bc9af71a7dc9eb46ba9e995e; Sun, 21 Aug 2022 13:59:28 +0000 (UTC) In-Reply-To: <87mtbxlnf1.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sun, 21 Aug 2022 15:46:26 +0200") X-Mailer: WebService/1.1.20560 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.187.31; envelope-from=luangruo@yahoo.com; helo=sonic308-56.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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:293710 Archived-At: Lars Ingebrigtsen writes: > Well, let me qualify that a bit: I think if we can make the default > non-Gtk toolkit version of Emacs pretty enough (and usable enough for a > reasonable user), and have compelling reasons to discourage the > Gtk-toolkit version (I think the _exit when a display shuts down, and > the XInput2 problems, might be compelling), then we might convince them. Prettyness is hardly useful when the software itself crashes. Especially with the modern idea of "pretty", which is rounded corners, low-contrast icons, animations and blur. Aside from that, the GTK build already has enough compelling problems for almost anyone to switch from it, just look at this part of etc/PROBLEMS: *** Emacs built with GTK+ toolkit can unexpectedly widen frames This resizing takes place when a frame is not wide enough to accommodate its entire menu bar. Typically, it occurs when switching buffers or changing a buffer's major mode and the new mode adds entries to the menu bar. The frame is then widened by the window manager so that the menu bar is fully shown. Subsequently switching to another buffer or changing the buffer's mode will not shrink the frame back to its previous width. The height of the frame remains unaltered. Apparently, the failure is also dependent on the chosen font. The resizing is usually accompanied by console output like Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed It's not clear whether the GTK version used has any impact on the occurrence of the failure. So far, the failure has been observed with GTK+ versions 3.4.2, 3.14.5 and 3.18.7. However, another 3.4.2 build does not exhibit the bug. Some window managers (Xfce) apparently work around this failure by cropping the menu bar. With other windows managers, it's possible to shrink the frame manually after the problem occurs, e.g. by dragging the frame's border with the mouse. However, some window managers have been reported to refuse such attempts and snap back to the width needed to show the full menu bar (wmii) or at least cause the screen to flicker during such resizing attempts (i3, IceWM). See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15700, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22000, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22898 and https://lists.gnu.org/r/emacs-devel/2016-07/msg00154.html. That bug is particularly nasty. I tried my best to get rid of it, but it still pops up once in a while, usually when the user switches to a Dired buffer, which has a very long menu bar. Despite the frame being maximized on some window managers, which is probably very annoying. I think the reason users use the GTK build despite those problems is because it is the default, and they don't know any better. Then, because they assume that the developers of a major toolkit are better at their job than us, blame for the resulting problems is assigned to Emacs, which results in shouting on the bug tracker. In the meantime, we have to endure the low-quality work of the GTK developers, in whose world files cannot be saved after the window server is shut down, and users and developers who turn off GTK mis-features are "clowns", "the internet peanut gallery", and have their knobs yanked out from underneath: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829 > But without the 1-5) I outlined, I don't think there's any chance > what-so-ever. Were they fine with the Lucid build before the GTK build became the default?