From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Add Tango and Adwaita icons for the toolbar Date: Sun, 05 May 2024 08:55:48 +0300 Message-ID: <86o79kera3.fsf@gnu.org> References: <87plu19ac7.fsf@yahoo.com> <7C9CBDCA-F058-46D4-9E40-63A18ABE34A7@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13596"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 05 07:56:38 2024 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 1s3UrV-0003Ip-Q1 for ged-emacs-devel@m.gmane-mx.org; Sun, 05 May 2024 07:56:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s3Uqn-0000UU-UC; Sun, 05 May 2024 01:55:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s3Uqm-0000UJ-C8 for emacs-devel@gnu.org; Sun, 05 May 2024 01:55:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s3Uqm-0001v0-2V; Sun, 05 May 2024 01:55:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Xwf/X6QMeBNfiWjEG3iRDya59l7TIP7+Dpuy2r+TcsM=; b=AMHZ7hTbv8AUPe42/ac3 4+eYph19U1Wbe8aUYGO+Nh55m0gYapp/AqxIMJA7XAeU3jxpyGzJKKgRvG3HyvV87xhhhiogCQLLM qi2DqFijhm/cLIMzapERPnv39T0swzNEPaC6gz2/M7vtXlRzBJiRHgRmD1yHA/g0gOKmSuVo98sbC +GBNN0YEmfJVoGmHQ/yro1WpRdau1MiUztshOBXH0qul0Zn5m7yupSLK4uhjp4kFAmr/S7ffuCrTC 4GaCwUUW0ZAohfahIJ4bplNW4HlJdn6jlt+NAkROANg63OVnn5S1PRyVdegd2ROcT7rDAfr4D1ONg scg4wNIzKu6Aag==; In-Reply-To: (message from Po Lu on Sun, 05 May 2024 08:22:08 +0800) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318770 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Sun, 05 May 2024 08:22:08 +0800 > > Yuan Fu writes: > > > I don’t think it’s necessary to generate XPM and BPM versions, because > > if you compare the new icons with the old, you’ll find that they are > > essentially the same icon (same shape, motif, etc). That is to say, we > > already have XPM and BPM version of the icons: the current ones. But aren't the new icons in the XPM format nicer-looking? If so, it still makes sense to prepare them in thee two formats, because Emacs can display them in its bare-bones build with no optional libraries. > The sizes and designs of the new icons are different from the originals, > and I will not stand for having even the _tool-bar_ icons be inferior > when this or that optional dependency is not available. Moreover, XPM > icons are better efficiency-wise on X, all the more so when the display > is on the other end of a wide-area network connection. I agree, new icons should be available in those two formats. > > Also the icons are in png format, the source is svg, but I exported > > the svg into png. Because svg isn’t rendered very well, presumably > > because theses icons are relatively complicated? (More complicated > > than the symbolic icons for sure.) > > If the display of the SVGs is inadequate, they would better be removed > completely. I'm not sure. We should collect user experience and perhaps make SVG be not the first priority, but there's no need to remove them completely, as someone might like them and/or have a librsvg implementation that doesn't have this problem. > > As for opting-out, there isn’t a mechanism to explicitly choose what > > version of icons to use in tool-bar.el right now. So it’ll need to be > > added. I believe the branch mentioned in the original discussion, > > created by Stefan K, has some mechanism for an “icon theme”. Maybe we > > can merge that, plus the new monotone icons in that branch, but left > > out changing the tool-bar icons? > > > > It’ll be a big project to find counterparts for all the current icons, > > plus I’m not a designer so I can’t conjure up icons by myself :-) I > > think we could make it opt-in first, and make it default when we have > > full coverage. We don't have to come up with counterparts for all the icons, provided that they could be mixed without cause unpleasant results. > Whatever you decide, please don't merge it into master until it is > ready. I suggest reusing the sctatch/icons branch for the time being. Agreed. A branch is also preferable for preserving the results of this work, even if we decide for now not to land it. Thanks.