Re: Rethinking the design of xwidgets

[Akira Kyle <ak@akirakyle.com>]

On Tue, Oct 13, 2020 at 06:12 PM, Corwin Brust <corwin@bru.st> 
wrote:

> Hi Aiko & Team Emacs!  Thanks for working on this.
>
> On Tue, Oct 13, 2020 at 4:33 PM Aiko Kyle <aikokyle@gmail.com> 
> wrote:
>>
>>
>> On Tue, Oct 13, 2020 at 12:36 PM, Tomas Hlavaty 
>> <tom@logand.com>
>> 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!