From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Platform independent graphical display for Emacs Date: Sat, 25 Dec 2021 15:24:42 +0200 Message-ID: <41b80f26-9522-e723-5999-c80a94427c5e@yandex.ru> References: <87ilvgwfor.fsf@telefonica.net> <83a6grx1o9.fsf@gnu.org> <834k6zwvi1.fsf@gnu.org> <87h7azilmu.fsf@yahoo.com> <87sfujh4a2.fsf@yahoo.com> <877dbuhm6j.fsf@yahoo.com> <87tueyg5gc.fsf@yahoo.com> <83y24asbh4.fsf@gnu.org> <83tuexqh7w.fsf@gnu.org> <9c04ef31-96e0-1874-7385-633435a28b5f@yandex.ru> <87tuew9a29.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13002"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: Eli Zaretskii , stefankangas@gmail.com, drew.adams@oracle.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 25 14:27:28 2021 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 1n1756-0003FP-3c for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Dec 2021 14:27:28 +0100 Original-Received: from localhost ([::1]:54430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n1752-0005VV-Dt for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Dec 2021 08:27:25 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40336) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n173f-0004jK-BE for emacs-devel@gnu.org; Sat, 25 Dec 2021 08:25:59 -0500 Original-Received: from [2a00:1450:4864:20::429] (port=36810 helo=mail-wr1-x429.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n173c-0005IN-Bw; Sat, 25 Dec 2021 08:25:58 -0500 Original-Received: by mail-wr1-x429.google.com with SMTP id r17so22421377wrc.3; Sat, 25 Dec 2021 05:25:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KQScsyg1aODyWB+9mHRphbtmvvG+EpUXeXXt6smKQ20=; b=oHyDfZw+L5dd35URIXyqVAtjg6SXauVQWmbD9usiA49lYe3s2n2hWtJmMDXbl6Hown EW4MadtNmv45Ux6UqVdu9IYBcRARpRrnLeMhsd3XnHAvDuzlJSrIt9U7Fz3K7dn62+M/ PvZGFLFDMqGRnhAxJAyqSOsK46ucg+NwhqWVo9Wku1TEikSrWWQ9VL2UNMu3zpw79XYg YfoD/NVX4i1hx3UnVIJJJiyZ4ygQr9HXoOqew+ej/uPXXbHzpbemiOtlZ3+DZ/klykpK Ogkx3rKXSFTWMVpCkN/YaYUonZi8TqSJ9ECqjcMNadDdrW+c814s3nsMmKJToIzlKueB 6pyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KQScsyg1aODyWB+9mHRphbtmvvG+EpUXeXXt6smKQ20=; b=kfVp7vOihdWO3es3HoOZC6WIfJslmolOrRmiUgfjGY4zOoXYAOJZzOFpermiv622aZ M4wGgP7acBgzcfJTFC0mdZq1V6U3YXKN0jnFVPGOlo2FbwdKhrT+o5xGl8gopVz2mTiX 3USitQbrbDcePJbLxak+DpjQ52xKYz2cDaX1D3GSBtIMc2j0n8XJhzE2iKpT1upX2Q1O RNByt9GmpkQze1b7gl2DrEHFlaEI+8JXXHSA0GUl45ACf370b1/XvKbhcLZPRPA02CU7 dTEkGF79Sz9iwK+r/UY//uITud7jbKv+RTE4mN+m0lLuA4DIuPFQknoaY3eQBunXSQsd 93tg== X-Gm-Message-State: AOAM532TPijLFfxT4l30X57TeDFcoguhhliDOTilbh1IxDseNjJzFEzw LimPSCmTrOaqLCE9LvLCn+vPT/9uxFg= X-Google-Smtp-Source: ABdhPJz0zxRrLIuvtzuSZL/1mJt6P/QWIZUHg58h6rjPsS8kl5RB3hAmlcc/CeEkTn9Yi78PKGxYcg== X-Received: by 2002:a5d:55c5:: with SMTP id i5mr7051699wrw.445.1640438754147; Sat, 25 Dec 2021 05:25:54 -0800 (PST) Original-Received: from [10.112.109.103] ([185.209.196.172]) by smtp.googlemail.com with ESMTPSA id p22sm18037321wms.2.2021.12.25.05.25.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Dec 2021 05:25:53 -0800 (PST) In-Reply-To: <87tuew9a29.fsf@yahoo.com> Content-Language: en-US X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::429 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::429; envelope-from=raaahh@gmail.com; helo=mail-wr1-x429.google.com X-Spam_score_int: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.196, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:283220 Archived-At: On 25.12.2021 14:51, Po Lu wrote: > Dmitry Gutov writes: > >> That should pretty much guarantee that it will be maintained. But the >> odds of reaching that point are pretty slim, of course, given that we >> don't lack in different viewpoints here. > > Maintaining a toolkit, even more so one that supports as many platforms > as we do, is not a one-person job, especially in this rapidly changing > world. > > Case in point: Wayland (which we definitely want to support.) AFAIK, no ports other than PGTK have any Wayland support either. So with the transition of GNU/Linux world from X to Wayland, we'd either have drop all other ports (aside from w32 and ns, I suppose), or end up dealing with this somehow anyway. > A single expert (or even a small group of experts) will have a very hard > time maintaining a toolkit that will work with Wayland, seeing as you > have to understand XML, a complicated wire protocol and several very > rapidly changing "standard" extensions to do any meaningful work with > it. For example, an unstable extension is required for a toplevel to > obtain the input focus, and another is required to handle input methods. > > Seeing as other programs such as Chromium (and by extension VS-Code) and > even toolkits with ample funding and full-time developers such as Qt > still struggle with Wayland support, I think it would be a very, very > bad idea for us to take that task onto ourselves. I suppose the hope at this point is that Wayland and set of its extensions will stabilize soon-ish, because it would also help with adoption by other programs. > Besides, we will probably not be able to implement everything on other > platforms such as NS, Haiku, or MS-Windows, so such a configuration will > likely be specific to X, which begs the question of why we should use > that configuration instead of the other in-tree X toolkit Lucid. Lucid doesn't look nice, nor does it support modern features like scaling. But for all I know, the potential developer could start with improving Lucid instead, and at some point reach the state where they are satisfied with how things work. After that, it might be a question whether people want to try unifying the w32 and ns ports too (by switching to rendering widgets with e.g. OpenGL). Or not. >> I would at least hope that switching to another no-toolkit >> configuration (and removing the current one soon after) is on the >> table. After getting enough consensus, naturally. > > You can't really switch "from one no-toolkit configuration" to another, > because they cannot be much different by definition. > > My idea of the only remotely practical way to implement a similar > configuration is for everything on the display (such as menu bars and > scroll bars, but not dialog boxes or popup menus) to be drawn by > redisplay through the RIF similarly to how the tool bar is displayed at > present in all platforms except NS and GTK. I think we can already do > that with the menu bar as well -- the only job that's left is to make it > look nicer, possibly by applying a box and a gray background to the > individual buttons there. > > Ideally, this won't require significant changes to the X specific code > at all. > > However, exposing that to Lisp would be a bad idea. If the tab bar > feature is anything to judge by, this seems to be quite difficult and > also tends to create obscure bugs, such as the image relief bugs with > the tab bar. Can't comment on that. >> It might become feasible to remove a number of them, though. If my >> hunch is right that people have been holding on to no-toolkit, or >> Motif, or Lucid, because they each have some pet bug which is present >> on newer toolkit ports, but not on their chosen one. > > People might also have a preference for Lucid or Motif, or even GTK+. > There are also people who want to use Motif/Lucid specific resources, or > GTK stylesheets. > > I hope we will not remove any of the toolkit code, no matter what. > >> Having a port like that developed could get us +1 such expect. > > That assumes someone exists and is willing to do the work. I don't > think we can magically "have" such a port developed and gain such an > expert. > > Would you like to volunteer? This discussion started with a person expressing interest.