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

[Akira Kyle]

On Sun, Nov 22, 2020 at 11:04 AM, Eli Zaretskii <eliz@gnu.org> 
wrote:

> > Awhile ago I started a thread on rethinking the design of 
> > xwidgets, there was a lot of good discussion about the future 
> > of 
> > Emacs' rendering capabilities. It personally motivated me to 
> > try 
> > to better understand how Emacs' redisplay works and just 
> > overall 
> > better understand the C core of Emacs. As part of that 
> > exercise, I 
> > decided to see if I could port the existing xwidgets code into 
> > a 
> > dynamic module. The only xwidget Emacs currently implements is 
> > a 
> > webkit widget, so this effort turned into creating a dynamic 
> > module for embedding webkit in Emacs. It also happens that I've 
> > been wishing that I could never leave Emacs and a general web 
> > browser was the last daily app that I begrudgingly used outside 
> > of 
> > Emacs. Anyways here's the result: 
> > https://github.com/akirakyle/emacs-webkit.git
>
> Thanks.
>
> So, IIUC, basically you create a buffer, display it in a window, 
> and
> then let GTK draw in the visible portion of that window, is that 
> the
> idea?  If so, what happens if some other Lisp inserts some text 
> into
> that buffer? does the text overwrite the WebKit display?

I find the GtkFixed widget that contains the windows of a frame, 
then I add the webkitgtk widget as a child of that GtkFixed. So 
everything under the widget is obscured, including any text 
written into the webkit-mode buffer. In fact I use the buffer for 
processing module->lisp async messages. I monitor for changes in 
the coordinates of the window with 
`window-size-change-functions`. Child frames are also added as 
children of the GtkFixed widget which presents a problem for 
things like posframe. I ensure that the webkit view is always 
below such child frames, as it would be if it were rendered as 
part of the buffer's window itself.