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: SVG widget in GNU Emacs Date: Wed, 27 Oct 2021 17:47:03 +0800 Message-ID: <874k92sstk.fsf@yahoo.com> References: <87bl3kcrpl.fsf@yahoo.com> <83ilxrc2ys.fsf@gnu.org> <875ytrc168.fsf@yahoo.com> <83a6j3c092.fsf@gnu.org> <87wnm7al92.fsf@yahoo.com> <835ytrbx8s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25747"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , Emacs developers To: Akira Kyle Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 27 11:48:30 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 1mffXp-0006XA-MI for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Oct 2021 11:48:29 +0200 Original-Received: from localhost ([::1]:58858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mffXo-0002Yv-F3 for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Oct 2021 05:48:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mffWo-0001r1-FX for emacs-devel@gnu.org; Wed, 27 Oct 2021 05:47:27 -0400 Original-Received: from sonic309-20.consmr.mail.ne1.yahoo.com ([66.163.184.146]:36577) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mffWm-0001E6-5X for emacs-devel@gnu.org; Wed, 27 Oct 2021 05:47:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1635328039; bh=MDt2bXo0LMkl6N3DyCiak3iykZFGsXtm9vlY7HF5KCM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=OCfckuYeZJxCFB9O4zMR73F0ruwDk40/YnUVsnzlgu31btkwCi3RVU0Pv9fy6kse/d/FphDCm0dJqv/TVYHJ9kWS3AjYr6pADxq638RzVWvmeZm7MEc9JWyo0t59X6YYI4PmqXGCjSHCTqOw6knQqPopUVPv8CRj8JnLAGQ+rfyzlAsG4H47Vy8NzckftZPTimtJoSfBqACPCre/v9O4yoUfnTBR771HHRml6phA4k90JbRqpIXk+yP2hJ7ClFRf8WD6jdbylgI/trikaVNBSh2R3OkUQodI2+dsSjQ1T5H9ORoTDF4kxBHeQ+NwpOiMz+WYxcnTejP9kpZJGy8+gg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1635328039; bh=0fotErxEILNllzhbs/8mxrkRS3vvClgeAOi/uJcCAQY=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=UytxqX46Y1LO1R8rZ0KApJmd5PAYCoviH8zskQpT4cSTzDM98rxqtlvThYHvHKYIO7SJgvj867seQ54KF9Q4PCUBWXxmfRwsVy0mQrdyE5YL1QSL6JWy57mviiCoremRGARxV/ns6uw1U5s0DsQXUV0ZTh0KP0QTrdkp4mu05OvkBGK0/ZMxKYEPPzcLN5vwtfMG3paLPX0cMX7CD672fOQr54KsZqyaCqbyk/8IE9P9OZkEEE5bknaPz91LBGJzMP9B9K0hS4iXKeu5v5hKdI6mEjUZXdx9rfXzjD4Ke+6YJXe5AUdn43aknVElpGxWCEr00k52jVKtN5F35guesQ== X-YMail-OSG: VlReD.EVM1noiv3D.OepAZ4GGFoNfvSzLmPL7b2LV4aDSXyzZFvSXfGuSPim5NI xADvxbd6T6n59JmURiAQR78.g4t4BsrtF_yEIew_4_1hG_wF6yXVdtVUKakIrVjXgldKYB2RRjyD qrs2AvxHdJBjdkWHdOJDEIA_UhBIbJSL2eBDpDF48xuqgzxgmBY1EdTLbGcKOWsEaUyTQzF87oC9 nQUmZtLZILHLdfnvE75O8FR.l0UK4xjQ0zyIVNKhNpxIzoCxpNSRRrCa0GvckkJjemzccgRaDCco pv_4OSZezXRUus2WyDslVhk82grC6W9x4_aNIC7JGL363ZVFDAzC4zD0l6II4uuR2JpFSHT7kj3g 3l12j5CcLSgVC7YZ_gx3TQUmCwYfvAR1K6AonZB2OnNMf6km76eYAET_4Zr6f0Y6t1q762nxJGkh qS8JTbUoFSUJEaIYp7iW2lWyIGXcO6XRfV9593uqoGvMyCSpDskDIMPMOhl6jqKsKhlN47KYb.Qk _bWZotQLG7IOhpuvolLoNbwM_UPOoXGxjY0Z0i16DAeYPJLtcuNbmLJuUrnXbvhh7bCdxP8nbCVX XCNWt99.YmPGNa2V4gRr7lneNSI.ETsG_joiFv_RKoY_0tRHKIi7HDw7x0xhGRgqjpfKLJTxbvR9 Hr2TcyCC7DCzo2y7nZRocW8YmMkvxdJ.FhpwSLNYSLmDyizTLngvC74kA8fpfbSO1K_1tfUT9Ah. 46tD2VU4ttvNeKuK.qh_cbv.d.dYluTzRAjeWLnJvmNGi3LtTLkOThz8LivvdckHgkeqDstNkDSy 2tGj3ydQbpfErKrXb.pn5mUU5CqxBakEK4IDIxNmQ4 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Wed, 27 Oct 2021 09:47:19 +0000 Original-Received: by kubenode501.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3c21dad20fb716f869b66293abc5fe1b; Wed, 27 Oct 2021 09:47:08 +0000 (UTC) In-Reply-To: (Akira Kyle's message of "Tue, 26 Oct 2021 00:32:55 -0600") X-Mailer: WebService/1.1.19198 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.184.146; envelope-from=luangruo@yahoo.com; helo=sonic309-20.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 autolearn=ham autolearn_force=no X-Spam_action: no action 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:277940 Archived-At: Akira Kyle writes: > IMHO the current xwidget implementation in emacs should deprecated. Even though it's not very polished at present, I've seen a great deal of code rely on the existing xwidgets support. I think it would be best to not make it obsolete. > Po, if you're seriously considering cleaning up this code, it might be > wise to take a step back and consider what features its trying to > provide and how. There's a fundamental tension between the > buffer/window model of emacs and the way gtk implements a MVC paradigm > that makes it nontrivial for them to be compatible. This situation has > only worsened as gtk has been moving its api's to better support a > future with heavy reliance on gpu rendering. IIRC this means the > offscreen rendering technique employed by xwidgets is being deprecated > in gtk. Furthermore xwidgets was implemented before webkit was > transitioned to a containerized worker process architecture so there's > bugs one has to work through as gtk attempts to take back control of > things like signal masks that emacs controls when it initializes gtk. > My impression has actually been that the nsxwidgets have worked far > better and reliably since that was merged (in fact I remember coming > across some emacs package out there that relied on xwidgets, but that > only supported it on macOS as something or another was broken with > xwidgets on gtk). I suspect the transition from x11 to wayland has > introduced a lot of bugs and difficulties for really complex gtk > widgets like webkitgtk. I understand what the problem in this area is. But I'd rather have the existing and (mostly) working xwidgets feature fixed than to waste time implementing a new one. > Ultimately I'd rather see effort go into getting pure gtk merged and > working to eliminate the mess of inpure mixtures of gtk and x11 code > from emacs (there could of course still be a "pure" X backend for > those who desire to run emacs with motif). I think as time goes on, it > will look worse and worse for emacs to need xwayland to run, as > distributions will stop including it by default. The pure GTK port will do nothing to resolve the issues here. I worked with that port a while ago, eventually porting it to GTK 4, but quickly lost interest not soon after that. In fact, I don't even see the problem with running Emacs in Xwayland. I've been doing that for years ever since Fedora switched to using Wayland by default, and I've never had any non-minor problems. All and all, the PGTK port still keeps the existing X11+Cairo display architecture. On the GTK3 version of that port, xwidgets still work like they do on X and NS. They will not work on GTK 4 anyway, as the GTK developers have deleted the ability to draw off-screen. > Also I think there's a lot of work to be done on xdisp.c. As I've seen > here and elsewhere, there seems to be sustained interest in richer, > flexible display options to support things like multicolumns or > buffers in buffers without resorting to clever hacks that work around > around the limitations of the current linear character arrays that > emacs represents buffer data as. Browsers with the DOM have obviously > already solved this problem in a very general way, and it's quite > popular these days to leave such complexity and optimization effort to > the browser engine devs and use something like electron. I doubt the > emacs devs or maintainers would ever consent to running emacs on top > of chromium or webkit (although there's already the effort to have > emacs run on servo here https://github.com/emacs-ng/emacs-ng but that It uses WebRender as a window system for Emacs, not Servo.