The xwidget branch origin story

There are some misconceptions about the Emacs Xwidget branch, and some people are just scratching their heads wondering what the branch is for. For me it is easier to answer these questions by regaling you with the very interesting origin story of the Xwidget branch!

I like making music and art in my spare time. I particularly like the particular electronic music genre called Live Coding. In this genre you code music live, and as the code changes, the music changes. It is a very interesting style for me, but there are some challenges of course. You don't have much time to think about your code, and you need to have fast feedback from your programming environment.

There are several Lisp based environments for live coding, and I like the Overtone one, which is based on the Clojure lisp and the Supercollider sound engine.

Mere's a tiny fragment from my project called Sylt.

(def d (industrial2)) (ctl d :wobble 1) (ctl d :wobble-vol 1) (ctl d :kick-vol 1) (ctl d :note 40) (ctl d :bpm 250)

The industrial2 function starts an algorithmic sequencer. You can change the wobble aspect of the sound by (ctl d :wobble 1), just by evaluating the code in Emacs with c-x e, just as you do with Lisp.

You can change the numerical constants with Emacs macrology and the like, and directly affect the sound. But wouldn't it be nice if you could have a slider controller right in your Emacs window, directly below the code? Emacs could parse the forms, with the Emacs parser infrastructure Semantic, and provide the slider just by parsing the code, or a comment. That would be really useful.

At the time I had recently provided the Imagemagic patch to Emacs. How hard could it be to make a slider? It should work more or less like an image object.

It turned out to be more complex than I thought at the outset, but it did work in the end. It was nice, because I could get a tighter loop between creativity and results.

Given that the infrastructure needed to have a slider component in Emacs would be more or less the same as any graphical component, how hard could it be to have a browser widget? The browser widget turned out to be very useful for me when working with things like animations in svg and html within emacs.

And that's the origin story of the xwidget branch. The basic idea is to have a tighter feedback loop, similar to what the REPL gives you when developing.

The xwidget_mvp branch, is a stripped down version of the xwidget branch that only provides the browser widget. The idea was to merge this branch to master first, and then resume work on the xwidget branch that has some further useful features. The xwidget_mvp branch should be understood as a stepping stone on the road to a larger goal.

I hope this also clears up the question of why you can't use a window manager hack instead of xwidget objects. The functionality in the xwidget branch provides a much deeper integration between the component and Emacs than you get with a window manager hack. You can access the components internals from Emacs. The xwidget branch for instance contains a (at the moment limited) interface between Emacs and the Gnome introspection model. As the interface matures, you would be able to call component methods directly from Elisp without writing C code.

Another thing that gets asked a lot is the xwidget name. I just combined 'x' meaning any, and widget, thus xwidget. I needed a prefix in the code. In retrospect the name wasn't very descriptive, because people believe that the branch is only meant for X windows, which it isn't, even if I only have tested it there.

Anyway, I hope this clears things up a bit.