emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rethinking the design of xwidgets


From: joakim
Subject: Re: Rethinking the design of xwidgets
Date: Tue, 13 Oct 2020 21:06:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Akira Kyle <ak@akirakyle.com> writes:

> 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.


Yes, I think that sounds more realistic than my original plan to expose
the gobject api to lisp.

>
>> 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.

BTW did you look at the widget that allows embedding of other
applications? I had some success embedding emacs inside emacs using this
widget, and maybe it has evolved during the years.

>> Anyway, thanks again for having a look at this!
>
> Of course!
>
-- 
Joakim Verona
joakim@verona.se



reply via email to

[Prev in Thread] Current Thread [Next in Thread]