Re: Rethinking the design of xwidgets

[Corwin Brust]

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