From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Mingde (Matthew) Zeng" Newsgroups: gmane.emacs.devel Subject: Re: Rethinking the design of xwidgets Date: Wed, 14 Oct 2020 15:24:08 -0400 Message-ID: <87pn5kehlz.fsf@posteo.net> References: <864kmzupp0.fsf@akirakyle.com> <835z7e2ouj.fsf@gnu.org> <86v9fet5sg.fsf@akirakyle.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33899"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.13; emacs 27.1 Cc: Eli Zaretskii , emacs-devel@gnu.org To: Akira Kyle Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 14 21:35:50 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 1kSmYv-0008gJ-NU for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 21:35:49 +0200 Original-Received: from localhost ([::1]:51896 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSmYu-0005WF-PB for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 15:35:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42132) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSmNg-0001zK-Qr for emacs-devel@gnu.org; Wed, 14 Oct 2020 15:24:12 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:54961) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSmNe-00025z-7Q for emacs-devel@gnu.org; Wed, 14 Oct 2020 15:24:12 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 843C3160060 for ; Wed, 14 Oct 2020 21:24:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1602703446; bh=off56Hc11Tsi/zsIJqBNAalpWYbZG4QyuqRUyArZaGU=; h=From:To:Cc:Subject:Date:From; b=GeiJf46tkFoWMF4vhppzPoGSZZKdPgT6dc6IqJWnSGlEuf3rW3FKGjRBiMO6xrcdu G9ULuH2f8XsMOiEx0Oa5qzgmvg3zlE3TTkFMd5B8HeiN70Mbrz+XXPVQws2VWrLzkZ fDwhywaGZ2z8WcQ2MSbTEtY36nIIYq/D/keNBWEz2rjAsr70crqQG3cvdAwTSPr5es gPoo63jLw4IcNbgYgWIrCykQamVYu8GicFibHH3Q8dioG1ab53jlcCa6KpgKyi7SAR x2p27axaRjgUGRMdcu/wFGbZptlqSoWYZvCY8pGA58UDFJwfJ0wyhqFpxy/0GcOAbA DSJWVbDAUQybA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4CBMm51387z9rxY; Wed, 14 Oct 2020 21:24:04 +0200 (CEST) In-reply-to: <86v9fet5sg.fsf@akirakyle.com> Received-SPF: pass client-ip=185.67.36.65; envelope-from=matthewzmd@posteo.net; helo=mout01.posteo.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/14 15:24:06 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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:257681 Archived-At: Hi Akira, > Another use case I had in mind for my proposed improved xwidgets is > better pdf rendering. I use pdf-tools constantly and it's one of the > best pdf viewers out there (not just because it's in emacs). I'll > sometimes even use it to give presentations so I never have to leave > Emacs. However it's design inherently limits its rendering performance > as it must rasterize each pdf page in a separate process then pipe > that data to emacs to display as an image. Granted this could be > avoided by turning the epdfinfo server process into a dynamic module, > however it will still be a bit roundabout as the pdf page would have > to first be rendered into a cairo context then rasterized then Emacs > will draw that rasterized image onto another cairo context to get it > onscreen. Having direct access to an onscreen cairo context would > eliminate this and make it easier to support crisp, performant > rendering onto HiDPI displays. Maybe I could even throw slide > animations into my presentations this way! You might've already tried it (since you mentioned in the main thread), but I still want to point out that currently the Emacs Application Framework's PDF-viewer [1] is probably your go-to choice (for now) for best PDF rendering in emacs, as it uses muPDF in the shadow. >From your main thread: > Unfortunately EAF uses Qt to reparent a window > into emacs and Python to do two way RPC with elisp. IMO it isn't a > very emacsy way to enhance Emacs' display capabilites and is limited > to just taking over a whole window rather than being embedded as part > of a buffer (key to supporting dynamic content such as an interactive > inline plot inside an org mode document). That leaves xwidgets which > seems to be somewhat incomplete, unused, and neglected. I've been > poking around the xwidgets code and I really like the concept, however > the implementation seems to need some more thought and work. As the maintainer of the EAF project, I have to point out that the original motivation for the existence of EAF was to enhance Emacs browser rendering, pdf rendering, and video rendering capabilites. The QGraphicsView was designed to span over the entire buffer to make it more emacsy, to fit the "one buffer, one major mode" idea. The choice was obvious when using EAF to view modern webpages, PDF, or videos. However EAF _doesn't have to_ stay this way, it is completely viable to embed the QGraphicsView inside a buffer. I don't completely understand your opinion on why EAF is not very emacsy, I can see why it's not lispsy, but EAF is keyboard-oriented, highly extensible and customizable. It just didn't improve Emacs itself but decided to utilize other free software. The author of EAF, manateelazycat, thought that it would take quite a long time for Emacs to improve its graphical capabilites of rendering webpages or videos to the point of other modern software dedicated for these functionalities, and emacs-devel should prioritize on making Emacs a better text-based editing environment, then the EAF's job is simply extending Emacs to the world of modern graphics. Nevertheless, I'm very interested to see how this xwidgets idea evolves. Matthew [1] Emacs Application Framework repo: https://github.com/manateelazycat/emacs-application-framework -- Mingde (Matthew) Zeng