From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Abysmal state of GTK build Date: Tue, 23 Aug 2022 09:19:26 +1000 Message-ID: <86h723esba.fsf@gmail.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> <87czctk890.fsf@yahoo.com> <87a67xlm9v.fsf@gnus.org> <87k070g6l0.fsf@yahoo.com> <8635do4u9b.fsf@gmail.com> <877d30g1az.fsf@yahoo.com> <86y1vg3a31.fsf@gmail.com> <87y1vgeho7.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2999"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.8.9; emacs 29.0.50 Cc: Lynn Winebarger , Lars Ingebrigtsen , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 23 02:11:34 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 1oQHW1-0000eM-PE for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 02:11:33 +0200 Original-Received: from localhost ([::1]:42840 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQHW0-0007yK-57 for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Aug 2022 20:11:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45420) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQHRr-0007pj-0K for emacs-devel@gnu.org; Mon, 22 Aug 2022 20:07:15 -0400 Original-Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]:43743) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQHRo-0003zS-R6 for emacs-devel@gnu.org; Mon, 22 Aug 2022 20:07:14 -0400 Original-Received: by mail-pj1-x1035.google.com with SMTP id o5-20020a17090a3d4500b001ef76490983so12986119pjf.2 for ; Mon, 22 Aug 2022 17:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc; bh=WUfwgK1g11zBO1aGsBYC6G3Kdb/Sh9C2SXwVmbnCW8Q=; b=N1hF/B2W9y0kMv9TW46ognEgVVNvqX0GmlEbvM6OsAkMqc2bG7Q+MmxJbXoCfZ1sJw mNZUYZXadlNeszV7cUx9eEOO4WS0Lj0tL5GJ2p0Xb5l9F2kO6oFuLIeNuPd4obehvneo Gz9u/S1ZAyuaa5IdxgjybDioSbSW5d57jRdIu1E8RKc8vLBPNwgYIrrZPIDZce/WKlaN DC0ktaitaJAY8IxlRbKXRNoiUIKBWMQFklAxiXG3mXc0IOilDhYOsqvi1cGltJGi2FzP Z0CwEaUUAGCnTrKeJnsNZN+TS2glAFsstH417Ar/B0CWHSqDSRp/FPtxauCeldxBXQ9z DCGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc; bh=WUfwgK1g11zBO1aGsBYC6G3Kdb/Sh9C2SXwVmbnCW8Q=; b=lgrnqpFOb4NCdpQyXMJH0ota/eo7Ta3H9gP83Xkxo4l/EVR5RpUbmGKi4PUzFj2Mu7 0oeoUe6C8oVbDMH3gbBbvSSFHPFFcERdKSv3flukIbld4HOOyl4SHq1Dbf87EJ/d3YPk 99A2Mu56ee48wJ2Jbm4JpAs8eG/SG+hqAYBfBYN8jnkBHUR5Qlz5lWC14z7tzJRRttXr c4hxkyVQwILcfUW8awNify4Ga83WU12UZwsXkHVuoNUL+kVy1z87uYcz/Tme4XOzFP+e ufLAOGUeY9miPT7k2+Eq7g9P23GB6dBuzlY2y9rLTTLu3wldxOrljWJ9Eu3mkudoIQGJ S87A== X-Gm-Message-State: ACgBeo0En5S/AYPlvIAPaN1Dn2Kmx7d6QATDXLFzVIcXZRYyfKmN0Zb9 XGBNlcke+ZS400Zc/avvwOtI2vH+3EAnvg== X-Google-Smtp-Source: AA6agR4ihHhLmJGrH1eS5PhFST2UHvapYFQ/2NUo1KbobAvp+Fy8G8J6SnU0X+IylIet0dNzFhttzw== X-Received: by 2002:a17:903:248:b0:172:7520:db04 with SMTP id j8-20020a170903024800b001727520db04mr22232787plh.99.1661213230869; Mon, 22 Aug 2022 17:07:10 -0700 (PDT) Original-Received: from dingbat (2001-44b8-31f2-bb00-842a-7361-87c7-2662.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:842a:7361:87c7:2662]) by smtp.gmail.com with ESMTPSA id c76-20020a624e4f000000b00535f2b5a23dsm8031777pfb.155.2022.08.22.17.07.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Aug 2022 17:07:10 -0700 (PDT) In-reply-to: <87y1vgeho7.fsf@yahoo.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::1035; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1035.google.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:293817 Archived-At: Po Lu writes: > Tim Cross writes: > >> You missed my point. I'm not saying the change is because of a stylistic >> issue - I'm saying the change is likely to create a stylistic >> issue. This will in turn cause more resistance to the change and >> possibly increase motivation to do whatever is necessary to re-enable >> gtk build. > > Reenabling the GTK build will be as easy as specifying > "--with-x-toolkit=gtk" at configure-time. It's not being deleted. > and again I feel your missing the point. Failing to address the stylistic questions runs the risk that most people will just re-enable the GTK theme. When this occurs, what have you actually achieved other than now being able to say "Oh well, you chose GTK, so now its your problem". What is really required is that the default is changed away from GTK and the majority of users are comfortable/happy with that change. This means somehow addressing concerns which people are likely to raise with a change in default toolkit. Dismissing them as irrelevant just because they represent some current trend/style you find distasteful is unlikely to help promote your proposal and gain acceptance. >> Yes, I know that and that is a problem for distributions where they want >> to minimise the distro size and number of packages which need to be >> maintained. As it stands now, most distributions include 3 packages - >> emacs-gtk, emacs-lucid and emacs-nox. As they move to support wayland, >> they will either have to include emacs-pgtk or continue with the >> wayland-x interface. The risk is, given they need GTK for both emacs-gtk >> and emacs-pgtk, they will drop the emacs-lucid package rather than the >> emacs-gtk package (unless we help educate them on why that would be a >> bad choice). To educate effectively, it helps to understand their >> situation and not just address the technical issues seen from a pure >> emacs development position. > > They don't need anything extra for emacs-notoolkit. > but they lose the ability to easily adopt a consistent theme across their desktop - something which for whatever reason appears to work now and will not once you change to either no toolkit or lucid. >> OK, so how does my Emacs default theme change between dark and light >> theme when I change the theme of my desktop environment? This never use >> to work and I assumed it was because emacs didn't respect the DE >> theme. I use to manage it via X resources. However, I noticed on recent >> installs under both Ubuntu and Fedora that changing between light and >> dark themes also resulted in changes to (for example) the menus and >> menu-bar from a light background with dark text to a dark background >> with light text. My assumption was that this was due to the GTK theme >> being respected? > > The menu bar is not part of Emacs's own interface. > I don't really understand what you mean with this above statement. From a user perspective, the menu-bar is obviously a part of the Emacs interface and when I switch to lucid or no toolkit, it changes to a light background and a dark foreground while everything else on my desktop honours my selection of a dark background and a light foreground. If I run the GTK build, the foreground/background is the same as the other apps on my desktop i.e. dark background, light foreground. As outlined at the very beginning, this consistency in themes seems to be something users want as can be seen in the prevalence of discussions and reviews regarding recent GNU Linux distribution releases which focus on this aspect. To minimise push-back and increase acceptance for a toolkit default change, addressing such side issues will likely help ensure a smoother transition. >> Which is fine for those who know lisp. However, this isn't what people >> expect these days. THis was my point - lots of the comments and reviews >> for recent distributions of Ubuntu and Fedora have referenced greatly >> improved theme/style consistencies. From my own limited experience, this >> appears to extend to Emacs as well (to a limited extent, not the whole >> UI, just menus, popup dialogue boxes etc. > > You can use Customize too, if you want. > still missing the point. Users don't want to be required to go through each individual application and manually adjust the theme to get a consistent looking desktop. They have selected a desktop environment and set a theme and want it applied consistently across the desktop. This appears to be something they have with current GTK build and which you don't get with lucid or no toolkit builds (at least on the Ubuntu and Fedora DE I've used, YMMV with other combinations). I don't know how easy it would be to address this issue - weather it would be possible to add a basic 'interface' package or script or document some alternative approaches to help people get the consistency which seems important with minimal effort. >> Ignoring the level of motivation visual appeal/style has to peoples >> decisions is likely to be somewhat naive. There are plenty of examples >> of superior technology/solutions losing to inferior ones because of >> non-technical reasons. > > That doesn't mean it's a good idea to base our decisions on those > non-technical reaspons. > and that isn't what I said or suggested. At the risk of repeating myself yet again, I'm not against the change in default toolkit. I'm merely suggesting that if you want to minimise the push back to this change and discourage people just manually selecting GTK, you need to also try and address these separate, but related issues. Dismissing them as just being irrelevant 'modern' trends will generate more heat and resistance than necessary. >> I also wonder about how frequent these crashes and technical issues >> are. I switched over from gtk to lucid a little while ago. However, >> prior to switching, I experienced absolutely no issues and I cannot >> recall the last time Emacs crashed for me. I'm running latest emacs >> devel (29.0.50) on Fedora 36 (previously on Ubutnu 22.04). I'm a heavy >> Emacs users, running it every day all day and using it for nearly >> everything. I switched to lucid because the technical arguments made >> sense to me. However, I did not experience any of the technical issues >> you reference. If my experience is more common, then your purely >> technical argument is going to have difficulty gaining traction. > > I'm going to say that you're simply lucky. Search for "GTK" on the bug > tracker, in etc/PROBLEMS, and on this list, and you will see what I mean > very quickly. However, that only gives a one sided view - all those people using the GTK build who don't experience any problems don't report all is OK. All I can report on is my personal experience. For me, I see no instability with the GTK build. I also see little of benefit to me with the switch to the new xinput2 and wonder why not just disable xinput2 in just the GTK build so that if/when users select GTK as their preferred toolkit, it is at least stable. I think it is quite reasonable to tell people that if they want the features, such as pixel level scrolling, then they have to use either no tookit or lucid and that the xinput2 features are not available in GTK. It seems misguided to just change the default from GTK to no toolkit or lucid and leave the ability to select GTK knowing that will cause instability due to the use of xinput2. Change the default AND disable xinput2 when someone selects the GTK toolkit.