Re: Multimedia dashboard in GNU Emacs

[Aiko Kyle <aikokyle@gmail.com>]

On Wed, Dec 29, 2021 at 9:48 PM Po Lu <luangruo@yahoo.com> wrote:
>
> > Doesn't this have to do more with syncronizing two DOMs though? There
> > isn't much gtk state attached to webkit webviews that would need to be
> > shared.
>
> The idea is to give the view a large enough allocation and to put it
> into a GtkScrolledWindow, which can then be scrolled however you want
> it.
>

As I see. So in this idea, the entire webpage would be rendered in the
case of a xwidget webkit? That seems like it would be costly for
especially large webpages.

> > Fundamentally the emacs window/buffer paradigm doesn't fit with the
> > browser DOM/webview paradigm.  This again goes back to my opinion that
> > enforcing a one-to-one correspondence between a webkit xwidget window
> > and buffer is the better UI paradigm for meshing the two than the
> > offscreen rendering technique.
>
> If an xwidget is only displayed in a single window, it behaves the same
> way as in any other application, so I see no reason to prevent it from
> being displayed in multiple windows.
>
> It won't hurt for the people who want it the way it is, and the people
> who want to keep an xwidget-webkit buffer from being displayed in
> multiple windows can simply refrain from opening those other windows.
>
> > I'm curious as to what your workflow/use case with them might look
> > like?  Understanding that might help me to better understand your
> > opinion on why the osr technique results in a better UI in this case.
>
> I'm not arguing about user experience (I have no opinion on that), only
> about what fits in better with the Emacs display architecture.

Do you then plan on implementing other xwidget types besides the
webkit one? I think with respect to the UI, osr makes more sense for
other widget types like buttons.

I agree the offscreen rendering is more general, however it seems to
me to add significant complexity that would be unnecessary if the UI
for it doesn't require it. Especially since the one-to-one webkit
buffer-window paradigm already has to be accounted for on ns, where
osr isn't available.