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: Rethinking the design of xwidgets Date: Wed, 14 Oct 2020 13:16:58 -0600 Message-ID: <86eem0bot1.fsf@akirakyle.com> References: <864kmzupp0.fsf@akirakyle.com> <835z7e2ouj.fsf@gnu.org> <86v9fet5sg.fsf@akirakyle.com> <87o8l6geh1.fsf@logand.com> <86h7qxu8ko.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9908"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.13; emacs 28.0.50 Cc: Tomas Hlavaty , Emacs developers To: Corwin Brust Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 14 21:21:37 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 1kSmLA-0002Qy-JJ for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 21:21:36 +0200 Original-Received: from localhost ([::1]:47238 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSmL9-0008Py-JH for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 15:21:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40438) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSmGk-0004q5-V5 for emacs-devel@gnu.org; Wed, 14 Oct 2020 15:17:02 -0400 Original-Received: from mail-il1-f193.google.com ([209.85.166.193]:45682) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kSmGj-0001Bm-2v for emacs-devel@gnu.org; Wed, 14 Oct 2020 15:17:02 -0400 Original-Received: by mail-il1-f193.google.com with SMTP id t18so547835ilo.12 for ; Wed, 14 Oct 2020 12:17:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=Za+QZxpZIX+f0WCuFA29GWqiyYySbFIduAHLlR1ZLbY=; b=sGEIW3chIULYyNU/KskRIPeqZ7/7nCI50ftaiCgweuacLO2O2A/4CRe+0DZtr44zrV r8UKnXJi1382dXQv8Y5Pm51wPSCqBEaTXO2p7iBHqJY72aWZlhD8ev1dCJaN3JlDfWGA 3d5lEGWW6WcO1c1OwNTMIBYj1f2JqmuVpXvqJH4AhyUXBja+O2K7FWyzmlQGWtaqZ5jW fnFj3tSgBnWODdNDlrYw5T/+spcQlJ9vlx1WTebcKkVky8f0Tr6K997uhDfvUe39ALem 03SVaX81PMCTgRjRC/fgHJX2atAKtX92rWxGG9800gvdi7iSGfsbh3sMVyxc6/rPLQvA eSvQ== X-Gm-Message-State: AOAM5309qeY2BNNRE0JM/tePJnLvKhExRPObl9XxKjpjbXj1ZKGYezoC VmQqB/tiia+FoR1CtR7XSdNbtbnjSDTPcZUr X-Google-Smtp-Source: ABdhPJyAyXBAK9VMkYSDgrOuJuKi38+4lnMnVomZceKet89buyyLTyiaO8UUEF26oDDfMyYhXLA8zw== X-Received: by 2002:a05:6e02:5ae:: with SMTP id k14mr593910ils.240.1602703019741; Wed, 14 Oct 2020 12:16:59 -0700 (PDT) Original-Received: from lore ([2601:281:8080:45f0:7f70:5415:b75f:2b9]) by smtp.gmail.com with ESMTPSA id c9sm403897iob.14.2020.10.14.12.16.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Oct 2020 12:16:59 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=209.85.166.193; envelope-from=aikokyle@gmail.com; helo=mail-il1-f193.google.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/14 15:17:00 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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:257679 Archived-At: On Tue, Oct 13, 2020 at 06:12 PM, Corwin Brust wrote: > Hi Aiko & Team Emacs! Thanks for working on this. > > On Tue, Oct 13, 2020 at 4:33 PM Aiko Kyle > wrote: >> >> >> On Tue, Oct 13, 2020 at 12:36 PM, Tomas Hlavaty >> >> wrote: >> >> > some kind of canvas was discussed in >> > id:87zh9hrxfj.fsf@logand.c >> > and >> > id:83img4aegz.fsf@gnu.org >> > >> > It was discussed in context of a WYSIWYG editor features, and >> > console >> > based pdf viewer emacs-frabuffer and pure elisp pdf generator >> > emacs-pdf. > > This sounds wonderful fwiw. > >> > Eli suggested: >> > >> > > If you want to do layout for PDF, I think one way >> > > forward >> > > would be >> > > to implement a pdfterm.c "terminal" for Emacs, which >> > > produces PDF >> > > like the existing *term.c backends do for supported >> > > display >> > > types. >> > >> > that might be better than some kind of xwidget >> >> I don't immediately see the connection of this proposal to >> mine. It seems like pdfterm would be a display backend like >> xterm >> that renders to PDF, however this is already possible using the >> x-export-frames command which uses cairo to render the emacs >> frame >> to. It seems like the hard part of making Emacs a WYSIWG editor >> isn't the rendering of the display to pdf, but rather all the >> features of a WISYWIG editor such as placement of arbitrary >> text >> boxes on screen. > > I wanted to offer a sample of a few things my pet project[0][1] > has > been able to do with SVG updates. While I won't get into our > aims*, > at least for now, we are finding the updates following the mouse > sufficient that I'm continuing in this direction. Nothing > attempted > with drag nor using alpha transparency thus far but this seems > like an > experient I'd be in a position to conduct if that may be > interesting. > We're fairly happy with a multi click interface so far, probably > given > the snap-to-point effect. > > Here is a direct link to a recent animated GIF. While the > sources > here are very, very ugly in my estimation a clean implementation > is > clearly possible. Moreover, it would be of keen interest if > such > things are available from core by the time our game works :) > > _Interactive Drawing Demo_ > https://bru.st/i/hUfqzqy48w.gif > > Perhaps less to topic and more as bonus bread-crumbs for someone > willfully curious, our project is aiming to store all user data, > including game sources (monsters, maps, characters, ...), in > org-mode > documents. So far this is working well; however, that design is > both > extraneous and too tightly coupled with respect to a more > serious > effort to replicate (or extricate) the interactive drawing > functionality here for more general purposes. It was somewhat > in this > vein, in fact, that I recently began extracting the "draw" > functionality from dm-map.el into dm-draw.el, which also omits > some > "predicate" logic used to decide which parts to render out "on > the > fly". Finally in this vein, our demos do their own scaling > (and > incur the associated performance cost), relating to our use-case > of > sending unscaled "spoiler" free SVG data from the host to the > player > clients. > >> > It is not clear to me, why a dynamic module would be better. >> > >> > For example, emacs-framebuffer can display svg images without >> > any >> > dynamic module by using external program, because emacs-nox >> > does >> > not >> > have cairo or librsvg or NS toolkit. >> > >> > Ideally, there would be a canvas (e.g. pdfterm) providing >> > low-level >> > drawing primitives (something like html canvas API) and the >> > rest >> > built >> > on top of that in elisp. > > Again fwiw, this is a nice fit in terms of direction for > dungeon-mode > - we are already rendering SVG, involving manufacturing DOM > nodes, > which seems to make for efficient processing and may also mesh > nicely > with unrelated work such as around an ebook reader feature iiuc. > > We took a hard-parts first mentality and success creating a > progressively rendering interface to display game maps has led > us to > try creating an interactive, visual editor for the maps. I've > submitted some talks related to the project; if some of these > are > accepted, and if there are any questions from this group, I > would be > happy to try working in responses to them, so that more > show-and-tell > experience is possible and recorded for whatever use it could be > down > the road. > > Corwin > > [0] dungeon-mode, overview: > https://directory.fsf.org/wiki/dungeon-mode > [1] dungeon-mode, src, etc: > https://git.savannah.nongnu.org/cgit/dungeon.git/ > [3] "dm-sketch", Monday, 2020-10-11 @ oops-its-the-am: > https://bru.st/i/hUfqzqy48w.gif Thanks for sharing! This is really neat and it looks like its coming along nicely!