Re: SVG widget in GNU Emacs

[Po Lu]

Akira Kyle <ak@akirakyle.com> writes:

> This is not true. Off-screen rendering of webkit views in NS does not
> work. See the comment at the top of nsxwidgets. The NS xwidgets
> implementation functions in the same (albeit slightly less elegant
> way) as emacs-webkit. Namely it enforces a one to one correspondence
> between the webview's buffer and it's window. When trying to display
> the webview's buffer in two windows, NS xwidgets will message "You
> can't share an xwidget (webkit2) among windows." and one window's
> contents will be blank. emacs-webkit handles this by always moving the
> webview to the focused window and changing the other window to the
> next buffer.

OK, my bad.  Sorry for that.

P.S. isn't emacs-webkit still a native module that runs within Emacs?

If that is true, then it means emacs-webkit (on GLib builds) will still
drive the GTK/GLib event loop through Emacs code (in xgselect.c), which
is identical to how X11 Emacs does it.

And then nothing prevents WebKitGtk from messing with the SIGCHLD
handler.

> I don't think it's fair to say that just because something works
> between emacs and NS, that it will work between emacs and gtk. While
> their paradigms are similar, we cannot know how similar or dissimilar
> their implementations are given that we cannot inspect the source code
> of NS.

One can inspect the source code of NS, through one of the two
implementations I'm aware of that have source code available: GNUstep
and the Cocoatron.  But I don't think that degree of access is
important, or even required, to determine basic implementation details
like this.

> Furthermore emacs does things differently in the impure X and gtk
> display code then it does in the pure gtk display code and the NS
> display code it was based on, especially as it concerns the display
> event loop.

But how is that a problem?  It doesn't affect the ability of
GtkOffscreenWindow to function correctly, for one.  I verified that long
ago.