[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rethinking the design of xwidgets
From: |
Akira Kyle |
Subject: |
Re: Rethinking the design of xwidgets |
Date: |
Tue, 13 Oct 2020 10:07:32 -0600 |
User-agent: |
mu4e 1.4.13; emacs 28.0.50 |
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!