Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)

[Eli Zaretskii]

> From: Akira Kyle <akira@akirakyle.com>
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> Date: Fri, 27 Nov 2020 13:56:25 -0700
> 
> > It is a relatively simple matter to disable some optimizations
> > when a widget is displayed.  It is also relatively simple to tell
> > the widget to redraw itself when redisplay changed its position on
> > the screen.
> 
> Yes, but you had previously pointed to that fact that xwidgets 
> needs to such disable such optimizations as part of the "kludge" 
> that would need to be resolved for xwidgets to be considered 
> viable for a path forward. Having looked at that, I'm not sure gtk 
> will ever want to cooperate without doing things that would be 
> considered hacks by gtk folks.

I'd appreciate more details on the GTK part of this.  I only said that
from the Emacs display engine side things are not too hairy.  from my
POV, xwidgets integration simply stopped short of going all the way
towards integration into the redisplay framework, and I don't think
anyone said before that this was done because better integration was
impossible or very hard.

> > I don't see why you consider this such a significant problem.  The
> > number of interfaces that such a "rich" display element needs to
> > support is very small and well-defined.  The problem with xwidgets
> > in this regard is that its interaction with the display code was
> > left unfinished, it basically just copy/pastes the code which
> > supports display of images, which is not 100% correct, since
> > xwidgets don't display a static bitmap.
> 
> The "number interfaces" will likely be small no matter what 
> solution is taken, its more about how easy you want to make it for 
> a "rich" display element to really mess with Emacs' display and 
> input handling. For example with xwidgets the onus is on the 
> widget implementation to not totally steal keyboard focus from 
> Emacs. I've found that gtk widgets really like stealing keyboard 
> focus so its easy to end up in a state you can't escape out 
> of.

Keyboard focus is a separate issue.  I only talked about integration
with redisplay.

For keyboard input integration, we'd need to develop some
infrastructure, if the existing one doesn't provide enough hooks.  If
you or someone else can describe the details, we could discuss that in
more practical terms.  I think it's too soon to give up on the
practical possibility to solve these problems before we discussed
that, or are even fully aware of the problems and the potential
solutions.

> Similarly gtk widgets won't always easily draw themselves 
> where you want at the size you want so its easy for widgets to 
> render, say, across window boundaries.

If that is true, then your method of letting the widget display in a
window won't work well either, right?  IOW, whether the screen area
given to the widget is a full Emacs window or just its part is not an
important aspect of the integration of such widgets into the Emacs
display.

> The xwidget approach requires non-insignificant work on the widget
> end to ensure the widgets will work within the confines of Emacs'
> redisplay.

As long as the widget can be told to use a given rectangular portion
of the screen, we should be fine: the current Emacs display engine is
perfectly capable of handling display elements that occupy an area of
certain dimensions.

> I'd think that such an interface to support "rich" display elements
> should be restrictive enough to not easily allow the "rich" display
> elements to misbehave.

Please tell more about the reasons for this conclusion.  I don't yet
see the difficulties you envision.