From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Akira Kyle Newsgroups: gmane.emacs.devel Subject: Re: SVG widget in GNU Emacs Date: Tue, 26 Oct 2021 00:32:55 -0600 Message-ID: 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; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28590"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 26 09:28:03 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 1mfGsM-0007Eo-0Y for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 09:28:02 +0200 Original-Received: from localhost ([::1]:55504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfGsK-0001NT-QK for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 03:28:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51366) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfG1M-0006dv-Gd for emacs-devel@gnu.org; Tue, 26 Oct 2021 02:33:19 -0400 Original-Received: from mail-lj1-f178.google.com ([209.85.208.178]:46711) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mfG1H-0007WF-BB; Tue, 26 Oct 2021 02:33:13 -0400 Original-Received: by mail-lj1-f178.google.com with SMTP id e2so1442754ljg.13; Mon, 25 Oct 2021 23:33:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CKsDLXZkwzLlz1a6nggyQxxLtj3BUNPlskXVxKRKtyw=; b=0QbtWY4WjY7UnDIgu+7oams76HMb0mcGNQ+4YM73cbiDPJIAgJ9vYmDDWYP0D9qUHH nGdvl2gjvEO6LhRHjrZZQ5l480WWXpqksbTfFK/pBREIoqfevPD+ST1icviAXmmjpwuL IVmcX8GYdMLRQM3T/zSP+9bZJEtciGKEBCsyIap74jYupSvJOjTihEU8vYPuva83mBJl H6YA+KzrDnCgTs0kgDSa1svpJSyWru56AhfJ9bruNF/gg5spOl75W1eRXYF4jB82HxE6 eBkV4ZY0ddgUdm8QqIYZftaY/3xVF8oQjGFRR9yppA8W5AeRBrd95cDwS8tlXC+agTEY 5G3Q== X-Gm-Message-State: AOAM53092GWXfX+OVSVX9QRhAKZYuAGwqJ6ujzPKs2huwqbobKWc3qho E4d93MKDgeaetHJtQ/QSqheIDNky9RyxsA== X-Google-Smtp-Source: ABdhPJzU46jHDTYBP8aP58TAjddwNw1NAweahaGsxG7duVrP/W5rucElKoHoLgFMvWObSczdkCPcag== X-Received: by 2002:a2e:9641:: with SMTP id z1mr25110891ljh.66.1635229986922; Mon, 25 Oct 2021 23:33:06 -0700 (PDT) Original-Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com. [209.85.208.169]) by smtp.gmail.com with ESMTPSA id u7sm164032lfs.46.2021.10.25.23.33.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Oct 2021 23:33:06 -0700 (PDT) Original-Received: by mail-lj1-f169.google.com with SMTP id q16so13919504ljg.3; Mon, 25 Oct 2021 23:33:06 -0700 (PDT) X-Received: by 2002:a2e:9bd6:: with SMTP id w22mr2971450ljj.339.1635229986332; Mon, 25 Oct 2021 23:33:06 -0700 (PDT) In-Reply-To: <835ytrbx8s.fsf@gnu.org> X-Gmail-Original-Message-ID: Received-SPF: pass client-ip=209.85.208.178; envelope-from=aikokyle@gmail.com; helo=mail-lj1-f178.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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.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:277820 Archived-At: On Wed, Oct 20, 2021 at 8:28 AM Eli Zaretskii wrote: > > > > Apart of the above, just look at xwidget.c and xwidget.el, and you > > > will see the FIXMEs, the incomplete doc strings, and other stuff left > > > unfinished. The idea was that those will get finished once the > > > feature is in the sources, but unfortunately it didn't happen. > > > > Indeed, I see your point. Thanks. > > > > I will probably work on this once I get the time. > > Thanks, cleanup in that area will be appreciated. IMHO the current xwidget implementation in emacs should deprecated. A year ago I spent some time digging into all of this and the result was my proof of concept emacs module that implemented the webkitgtk functionally independent of xwidgets, called emac-webkit (https://github.com/akirakyle/emacs-webkit and there's a thread that I started here about a year ago to discuss this). The webkitgtk part of xwidgets really is the only functional part, since the buttons and other widgets have only an incomplete lisp interface and implementation. 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. 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. 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 just adds servo as a gui toolkit and doesn't attempt to touch xdisp.c). So that leaves it to someone to really understand xdisp.c enough to extend it in such a way that maintains the optimizations people care about for text terminals, while allowing richer data structures to be displayed efficiently by the modern gui toolkit paradigms. No easy task. Sorry for the long reply. I end up thinking about this topic whenever I get frustrated with emacs' display engine. I wish I had the time to work on this, but alas I've started grad school and don't even have time to work emacs-webkit much.