Re: Rethinking the design of xwidgets

[Akira Kyle]

Hi Joakim,

On Mon, Oct 12, 2020 at 04:18 PM, joakim@verona.se wrote:

> As the original author of the xwidgets code, I'm happy that you 
> are
> taking an interest in moving the idea forward, and I like your 
> ideas.

Thanks! And thank you for doing the hard work of initially 
figuring out how to integrate xwidgets into Emacs' redisplay.

> I had these ideas in the same vein originally:
>
> - Use the gnome object system to create and manipulate xwidgets
> dynamically. There was a prototype for this in the original 
> xwidget
> branch. It worked, but it was tedious figuring out how to map 
> between
> elisp types and gtk types.
>
> - In those cases when the gobject bridge didnt behave, use the 
> emacs
>   module system for shims(the approach you describe above)

My current understanding is that there isn't a plan to have elisp 
support a ffi, and the dynamic module system should be used 
instead. Given the small interface of the module system, I can see 
how it would be very tedious and difficult to figure out how to 
expose the large gobject and GTK api to elisp purely through the 
dynamic module system. I think my goal is much less ambitious: 
Rather then attempting to expose buttons, sliders, cairo surfaces, 
and all the variety of gtk widgets for elisp to manipulate (which 
also would be difficult to make portable to other GUI toolkits 
like cocoa), I simply want to expose a mechanism for a module to 
add a widget to a buffer. It would be up to the module for 
defining the right level of abstraction in exposing an elisp 
interface to the widget it creates.

> Some questions:
> - The original xwidgets were designed to allow several views to 
> the same
> xwidget using gtk reflection, as you describe. When I tried 
> using
> separate gtk controllers on screen, they didnt sync very 
> well. Did you
> try this and did it work well?
>
> When I worked on this I tried several different gtk components 
> such as
> sliders etc. Some of the worked flaky, some worked rather 
> well. What is
> you current experience trying different components?

So far I've started pretty simple and just looked at buttons and 
sliders, where each view gets it's own instance of the widget (so 
no offscreen rendering). The synchronizing of state is all handled 
by connecting each view's widget to a common signal handler which 
then updates the state of all the other views. So far the slider 
appears to sync its state pretty well across the views, but I have 
yet to look at more involved widgets.

> Anyway, thanks again for having a look at this!

Of course!