From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Juan =?utf-8?Q?Jos=C3=A9_Garc=C3=ADa-Ripoll?= Newsgroups: gmane.emacs.devel Subject: Re: Interest in nt_load_image? Date: Mon, 30 Mar 2020 18:15:47 +0200 Message-ID: <86r1x9rf7w.fsf@csic.es> References: <86369r0xcv.fsf@csic.es> <83k1324m60.fsf@gnu.org> <86imimwa4t.fsf@csic.es> <838sji3qhx.fsf@gnu.org> <86lfnhsyei.fsf@csic.es> <83v9ml3kpx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="98825"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (windows-nt) To: emacs-devel@gnu.org Cancel-Lock: sha1:VjqblfyfPGKfWWf9eYoP5nMGAew= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 30 18:16:56 2020 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 1jIx5s-000PXI-05 for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Mar 2020 18:16:56 +0200 Original-Received: from localhost ([::1]:52348 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIx5r-00063G-3P for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Mar 2020 12:16:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47416) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIx4w-00059o-75 for emacs-devel@gnu.org; Mon, 30 Mar 2020 12:15:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jIx4u-0002B1-Gx for emacs-devel@gnu.org; Mon, 30 Mar 2020 12:15:58 -0400 Original-Received: from ciao.gmane.io ([159.69.161.202]:45452) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jIx4u-0002AH-AW for emacs-devel@gnu.org; Mon, 30 Mar 2020 12:15:56 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jIx4s-000OBo-KN for emacs-devel@gnu.org; Mon, 30 Mar 2020 18:15:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 159.69.161.202 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:246027 Archived-At: Eli Zaretskii writes: >> From: Juan José García-Ripoll >> >> Date: Mon, 30 Mar 2020 16:36:05 +0200 >> >> >> I have also verified that it is possible to convert all *.xpm icons >> >> to *.png format and thus eliminate the need to include >> >> libXpm-noX.dll. Plus, the size of the icons is reduced by 50% >> > >> > We aren't going to get rid of XPM icons in the distribution any time >> > soon (because of other platforms), so I don't see an urgent need to do >> > this. >> >> No. I did not mean to replace the xpm icons in the sources, but instead >> distribute emacs without depending on libxpm-nox, at least on Windows. > > At 84KB, I don't see how the XPM DLL could be a problem for anyone. > More importantly, tool-bar.el explicitly loads XPM icons. Not really. tool-bar.el uses find-image which can be trivially extended to also seach for PNG as last resort. This is what I showed in my previous message with a screenshot. Also I am just trying to address Phillip's complaint about keeping track of the dependencies. I agree that having to manually download and copy libxpm-nox.dll is just one more complication that, in the Windows case, is not needed. This would also make the *-no-deps.zip file only dependent on libgmp.dll and nothing else. diff --git a/lisp/tool-bar.el b/lisp/tool-bar.el index 7df1e28..d0aef3d 100644 --- a/lisp/tool-bar.el +++ b/lisp/tool-bar.el @@ -150,16 +150,20 @@ tool-bar--image-expression (xpm-spec (list :type 'xpm :file (concat icon ".xpm"))) (xpm-lo-spec (list :type 'xpm :file (concat "low-color/" icon ".xpm"))) + (png-lo-spec (list :type 'png :file + (concat "low-color/" icon ".png"))) (pbm-spec (append (list :type 'pbm :file (concat icon ".pbm")) colors)) (xbm-spec (append (list :type 'xbm :file - (concat icon ".xbm")) colors))) + (concat icon ".xbm")) colors)) + (png-spec (append (list :type 'png :file + (concat icon ".png")) colors))) `(find-image (cond ((not (display-color-p)) ',(list pbm-spec xbm-spec xpm-lo-spec xpm-spec)) ((< (display-color-cells) 256) - ',(list xpm-lo-spec xpm-spec pbm-spec xbm-spec)) + ',(list xpm-lo-spec png-lo-spec xpm-spec png-spec pbm-spec xbm-spec)) (t - ',(list xpm-spec pbm-spec xbm-spec)))))) + ',(list xpm-spec png-spec pbm-spec xbm-spec)))))) >> However, regarding "ancient" windows machines, GDI+ was introduced in >> Windows XP and Windows 2000 >> (https://docs.microsoft.com/en-us/windows/win32/gdiplus/-gdiplus-gdi-start). It >> hardly gets older than this with working machines, does it? You would have >> to go back to Windows 98 or NT 4.0, whose support ended 17 years ago. > > I know. Believe it or not, we do still support those old version (or at > least try not to break their support knowingly). You will see that in many > places in the w32-specific code, for example we load unicows.dll and call > MultiByteToWideChar through a function pointer. I believe this executable cannot be built in older versions, as msys does not even support Windows XP. It pobably also does not run there. What would you use to build it? Are there any regression tests for those platforms? >> >> + if (STRINGP (specified_bg) >> >> + ? FRAME_TERMINAL (f)->defined_color_hook (f, >> >> + SSDATA (specified_bg), >> >> + &color, >> >> + false, >> >> + false) >> >> + : (FRAME_TERMINAL (f)->query_frame_background_color (f, &color), >> >> + true)) >> > >> > Do we really need to go through the hook mechanism here? The frame >> > type is known in advance, right? >> >> This code is not testing for frame type, but whether the background was >> specified as an argument for image creation (uses the given value), or not >> (it then uses ->query_frame_background). I just copied this form image.c, >> which is where the determination of the PNG background color takes place >> when libpng is used. > > image.c is mostly platform-independent code, but this isn't: the result of > > FRAME_TERMINAL (f)->defined_color_hook > > and its ilk, i.e. what functions will be called, is known in advance. Why > not call those functions directly? You assume too much of me. I do not know what is going on there under the hoods. And your question also applies to the code in image.c that uses this exact piece of code, and which is in the non-platform-dependent part (HAVE_PNG section). > I'm not really bothered by additional dependencies or by the disk space they > take. My main motivation is to give users more options and features to use, > because I'm quite sure the results will not be identical, so sometimes one > method will be preferable, and sometimes the other. This makes Emacs more > future-proof, which on a platform such as MS-Windows is no small feat. My motivation on this particular contribution is not space, but removing external dependencies and making the code more robust. Building the Windows port around GDI+ makes it also more future proof: if GDI+ support is dropped in the near future (which I doubt, given it is also supported by Direct2D), it can be almost trivially replaced with Windows Image Component, which is the more modern interface. Cheers, P.S.: Just a side question, is LCMS2 actually used anywhere in Emacs? -- Juan José García Ripoll http://juanjose.garciaripoll.com http://quinfog.hbar.es