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: Tue, 23 Aug 2022 08:57:36 +0800 Message-ID: <87k06zbwu7.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> <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> <86h723esba.fsf@gmail.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="23795"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: Lynn Winebarger , Lars Ingebrigtsen , emacs-devel@gnu.org To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 23 02:59:12 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 1oQIG7-00066K-Qf for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 02:59:11 +0200 Original-Received: from localhost ([::1]:38800 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQIG6-00073l-Np for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Aug 2022 20:59:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60820) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQIEo-0006Er-Ok for emacs-devel@gnu.org; Mon, 22 Aug 2022 20:57:50 -0400 Original-Received: from sonic301-30.consmr.mail.ne1.yahoo.com ([66.163.184.199]:39132) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQIEm-0004Am-Ek for emacs-devel@gnu.org; Mon, 22 Aug 2022 20:57:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1661216265; bh=Uy0Qs2pm0lN6CUdPCLIw4EjSRsxqOLwYOXrEptUei20=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=TzqJbeJkG4qwYqNbUYb8hrQAr0fGDVzZCrKfHD4SKw3w6gXoJLfE7NHdgk9JERln2ymYrOh+bXQ1YnjrMBvsugpqmuaz51PhKD6JLuSi92gbzx/ce9h2wGdY+i+xxm6TyQMCTOUGMWUPise6ldhSGg03upEOcZxK1zp0Bjrc1Bk+PRoxwvIAVpa/W8OhAEuRsNEO2lOkpCfmq+jvnvJoiSB94a/roWl279Bf0PPA3Qsei/6/UbzgWlJ3hLeJuom9czDjYGzrU9yk/Hm+2Wca8dCTQkoT9g/+5194sNm5m4t/VJyVsRPpMBRnFkhxUHtirrO+8RAyCQiXu8jNlRMMvw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1661216265; bh=XreB+GtVudSwcxr+FqdprHDrmqicpGISCmuJItZEQgM=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=gNEzVo50NH9/W/PEyxboP8PCERg0NxayqZRFztLWW7cZ6co0oCG96qEQ/iaSBhQeRspdXhqBtilDdtcoSbgGmeMpjiWYJZJxwwTgp8Mppti3xcZL9ovWeSCTVkxmSGgxNvvc3XHqbYxDGB0bE8b6wXciKjbxvkJaKvWaGA2Cq2mF90ARY+Gcb9Ft51ciJ0YA8r8FKOeVtA7TFlYjdwoPu+pZv1d0v+1m2QZ+CFlAUwAWcTYPKiplLsXtCEc6wkmBG39C45KgNpkU0Fg77/SewrFrYG7339C1K39F19wjwlwe2QtJodckEjOrQeLNxdSiuPEljGYBIFj8OIDQ9BYlpw== X-YMail-OSG: fNXyna4VM1kzHoAUzXMH.yFpOM45IycRbT1L35pgZubUk2hBSPmCKcYTfeaKwEF xbTkOgRL44lUS4w75j4MTpdiLksyIMB9YPwOuL8x37Sr57BI.3Z1tDPLKQSrHbxNsFfy9k1NnIU. 9Z6jrGydPb74MBsMVDL7EeDAgAaCSm60lWbOhxS.86kyEJypabQRyJ_AJuRE.prMQr2ykjiC6y5T uxs7J1Dh.KzcyNWeuTA88w.pxmz5IvlpaXtucrXLcQ6iXnyy_m.a1Wfh5I9pirAvU6AOoWp6BDP4 VR0WqpdV9x37YoFZsw5FBiWObMhGOQW8XM3pk07zmeqPMEPEdb4VS4UIZ3ukORbudvgKw_B7PJw2 8GftanYdMrMmWFkpZgqeXZFmIXeNwWFy7XovvMWl5fy5.d4xUo1I9nQh0NjlfTorxOgHj3xD1tTd Cvv1RmNdrta4rP9TNwX_nTBcPxgYdiNUodip9ZSGgPQL5Be55SNO1tOHsuHm95UDPfIdFh_ByNe4 Y_e1kCa_UBDpNwVyGcqb5v1r34nYyYuTLkQjGOECajX83_FfBGZUivtGn8..BUbw_g5iJ9QUNj6z BQmt9_8Wh0Mj6WT8D460b9be.6p.P5CYVCqeIR4EepQGRq6j5J5KcVeYyDIEZFXDyrzHjFIrbW3L P_WEcQFZezGOKFzLLdJVeEYYy.2G5UUAt96o35jq0oe9J9kWN8b9KImLrSbkWwTl9dkaox7xjYVv jRMNKBQb_RyWrLFNxsuzyEdchxARu_cAJUP.qYS9m9h1h_HGYyRkCVeDRH944db4Rq6QCiLaFhJn ap2jEhmupd2sMuYiwWffgvU.aE6njGygOsyKWEOWGZ X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 23 Aug 2022 00:57:45 +0000 Original-Received: by hermes--canary-production-sg3-6f58cd9b5-slt79 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 64e08b929ab4bb62607f6e0731047cc5; Tue, 23 Aug 2022 00:57:41 +0000 (UTC) In-Reply-To: <86h723esba.fsf@gmail.com> (Tim Cross's message of "Tue, 23 Aug 2022 09:19:26 +1000") 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.184.199; envelope-from=luangruo@yahoo.com; helo=sonic301-30.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, RCVD_IN_MSPIKE_H2=-0.001, 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:293824 Archived-At: Tim Cross writes: > 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". If they run into problems in GTK at that point, we can just shrug and ask them to complain to the GTK developers. > 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. I wouldn't call a stylesheet applied to only the menu bar and scroll bar "consistent". It is hard to keep a GTK stylesheet consistent anyway, because their developers keep breaking the stylesheet format, and now there are GTK 4 programs that do not allow applying custom styles at all. > 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. So, in other words, you're fine with the menu bar being consistent with the system stylesheet (something the GTK developers say not to apply, and have outright deleted from many GTK 4 programs), while a Gnus summary buffer is not? > 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. Again, see what I said above. > 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 don't want to discourage people from manually selecting GTK. > 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. Because the core input subsystem is obsolete, like Xinerama, multi-buffering, the original input extension, core fonts, and RandR before 1.2. It will not even work with new input devices in the future, or under multi-pointer X environments, and the support in GTK itself will be removed by GTK developers at some point. Do this: xinput create-master test 0 1 xinput reattach and try to click on a frame from programs not using the input extension. It will not work.