From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Optional support for GDI+ on Windows (emacs-28) Date: Wed, 01 Apr 2020 18:45:34 +0300 Message-ID: <83a73vyztt.fsf@gnu.org> References: <86lfnh8wzn.fsf@csic.es> <83pncs1ulv.fsf@gnu.org> <86ftdoedvh.fsf@csic.es> <83d08s1nf9.fsf@gnu.org> <831rp81kfs.fsf@gnu.org> <83h7y3z61m.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="75357"; mail-complaints-to="usenet@ciao.gmane.io" Cc: juanjose.garciaripoll@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 01 17:47:31 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 1jJfaT-000JVT-RS for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Apr 2020 17:47:29 +0200 Original-Received: from localhost ([::1]:33776 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJfaS-0001tm-SX for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Apr 2020 11:47:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52331) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJfYk-00008Y-2c for emacs-devel@gnu.org; Wed, 01 Apr 2020 11:45:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jJfYj-0004VD-NT; Wed, 01 Apr 2020 11:45:41 -0400 Original-Received: from [176.228.60.248] (port=2841 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jJfYi-0000Zf-Dt; Wed, 01 Apr 2020 11:45:41 -0400 In-Reply-To: (message from Stefan Monnier on Wed, 01 Apr 2020 10:58:29 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:246205 Archived-At: > From: Stefan Monnier > Cc: juanjose.garciaripoll@gmail.com, emacs-devel@gnu.org > Date: Wed, 01 Apr 2020 10:58:29 -0400 > > > I didn't request anything that could be qualified as jumping through > > hoops. This is our standard implementation paradigm for optional > > features on MS-Windows, you can see it all over the place in w32*.c > > files. Convenience macros are available to make coding this > > more-or-less copy-pasting from some other similar feature. > > I don't think "variables to control whether is used for each > supported " is comparable to what we do for other > "optional" features on MS-Windows. Actually, it is comparable. See w32-unicode-filenames, as one example. Another example is the font-backend frame parameter, which controls what shaping engine will be loaded and used. > Also, for "optional features on MS-Windows", the usual behavior if the > lib is not available at run-time is just not to provide the > corresponding functionality, rather than to fallback on some alternative > C implementation. In most cases, but not all of them. See above. > IOW, I think what would be comparable is: build with support for GDI+ > images only (i.e. without support for images via libpng and friends), > and make sure Emacs does run even if GDI+ is not available (simply with > the limitation that it can't display those images, just like what we > have now if libpng is not available at run time). I don't think it is correct for us to commit ourselves to GDI+ right now. We should first see if it is a 100% capable replacement, and learn about its advantages and disadvantages. We always do that with new optional features: they start disabled. In this case, we should also consider whether GDI+ will be supported long enough before MS comes up with the next buzzword and decides to deprecate GDI+ (something that happened with Uniscribe, for example). This dependence on MS whims is one significant disadvantage of using the native capabilities where ports from Posix are available as replacements. So, by and large, I don't think it's reasonable to rush to GDI+ without collecting experience first, and having those optional knobs is necessary for that.