The xwidget branch origin story

[joakim]

There are some misconceptions about the 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 Lisp 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. 

-- 
Joakim Verona