The xwidget branch origin story

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

Re: The xwidget branch origin story

[John Wiegley]

>>>>> joakim  <joakim@verona.se> writes:

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

Thanks for the background history, Joakim! And yes, until I read this, I had
thought it was only for X11 as well. :)

John

RE: The xwidget branch origin story

[Drew Adams]

> > 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.
> 
> Thanks for the background history, Joakim! And yes, until I read this, I
> had thought it was only for X11 as well. :)

Why not rename it?  Emacs Lisp has stuff that uses the prefix `x-',
and at least originally, that stuff had to do with X Window.  Most
of it has been renamed to drop the `x-'.

Since `xwidget' is misleading people, and the `x' doesn't help in
any way, please just rename it.  But we also already have Emacs
code concerning widgets, so maybe try to come up with a name that
is specific to these particular widgets or their use.

Re: The xwidget branch origin story

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> Since `xwidget' is misleading people, and the `x' doesn't help in any way,
> please just rename it. But we also already have Emacs code concerning
> widgets, so maybe try to come up with a name that is specific to these
> particular widgets or their use.

Even ewidgets would be better.

John

Re: The xwidget branch origin story

[joakim]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Drew Adams <drew.adams@oracle.com> writes:
>
>> Since `xwidget' is misleading people, and the `x' doesn't help in any way,
>> please just rename it. But we also already have Emacs code concerning
>> widgets, so maybe try to come up with a name that is specific to these
>> particular widgets or their use.
>
> Even ewidgets would be better.

I can rename the feature and the right time would be now before merging
it to master.

But since I obviously fail at coming up with good names, I need some
help. John?



>
> John
>

-- 
Joakim Verona

Re: The xwidget branch origin story

[Michael Abrahams]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

ewidgets, egtk, gtk-widgets, emacs-widgets, elisp-widgets, elisp-gtk,
elisp-gtkw

On Sun, Nov 22, 2015 at 8:56 AM, <joakim@verona.se> wrote:

> John Wiegley <jwiegley@gmail.com> writes:
>
> >>>>>> Drew Adams <drew.adams@oracle.com> writes:
> >
> >> Since `xwidget' is misleading people, and the `x' doesn't help in any
> way,
> >> please just rename it. But we also already have Emacs code concerning
> >> widgets, so maybe try to come up with a name that is specific to these
> >> particular widgets or their use.
> >
> > Even ewidgets would be better.
>
> I can rename the feature and the right time would be now before merging
> it to master.
>
> But since I obviously fail at coming up with good names, I need some
> help. John?
>
>
>
> >
> > John
> >
>
> --
> Joakim Verona
>
>

[-- Attachment #2: Type: text/html, Size: 1406 bytes --]

Re: The xwidget branch origin story

[joakim]

Michael Abrahams <miabraha@gmail.com> writes:

> ewidgets, egtk, gtk-widgets, emacs-widgets, elisp-widgets, elisp-gtk, elisp-gtkw

While there is  currently only an gtk implementation of xwidgets
available, gtk is not supposed to be a hard limitation. Therefore I would like the
name to not include gtk.

That leaves, from the above suggestions:

ewidgets, emacs-widgets, elisp-widgets 

>
> On Sun, Nov 22, 2015 at 8:56 AM, <joakim@verona.se> wrote:
>
>
>  John Wiegley <jwiegley@gmail.com> writes:
>
>  >>>>>> Drew Adams <drew.adams@oracle.com> writes:
>  >
>  >> Since `xwidget' is misleading people, and the `x' doesn't help in any way,
>  >> please just rename it. But we also already have Emacs code concerning
>  >> widgets, so maybe try to come up with a name that is specific to these
>  >> particular widgets or their use.
>  >
>  > Even ewidgets would be better.
>
>  I can rename the feature and the right time would be now before merging
>  it to master.
>
>  But since I obviously fail at coming up with good names, I need some
>  help. John?
>
>  >
>  > John
>  >
>
>  --
>  Joakim Verona
>
>

-- 
Joakim Verona

Re: The xwidget branch origin story

[Michael Abrahams]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

One more, el-widgets

On Sun, Nov 22, 2015 at 2:19 PM, <joakim@verona.se> wrote:

> Michael Abrahams <miabraha@gmail.com> writes:
>
> > ewidgets, egtk, gtk-widgets, emacs-widgets, elisp-widgets, elisp-gtk,
> elisp-gtkw
>
> While there is  currently only an gtk implementation of xwidgets
> available, gtk is not supposed to be a hard limitation. Therefore I would
> like the
> name to not include gtk.
>
> That leaves, from the above suggestions:
>
> ewidgets, emacs-widgets, elisp-widgets
>
> >
> > On Sun, Nov 22, 2015 at 8:56 AM, <joakim@verona.se> wrote:
> >
> >
> >  John Wiegley <jwiegley@gmail.com> writes:
> >
> >  >>>>>> Drew Adams <drew.adams@oracle.com> writes:
> >  >
> >  >> Since `xwidget' is misleading people, and the `x' doesn't help in
> any way,
> >  >> please just rename it. But we also already have Emacs code concerning
> >  >> widgets, so maybe try to come up with a name that is specific to
> these
> >  >> particular widgets or their use.
> >  >
> >  > Even ewidgets would be better.
> >
> >  I can rename the feature and the right time would be now before merging
> >  it to master.
> >
> >  But since I obviously fail at coming up with good names, I need some
> >  help. John?
> >
> >  >
> >  > John
> >  >
> >
> >  --
> >  Joakim Verona
> >
> >
>
> --
> Joakim Verona
>

[-- Attachment #2: Type: text/html, Size: 2226 bytes --]

Re: The xwidget branch origin story

[John Wiegley]

>>>>> Michael Abrahams <miabraha@gmail.com> writes:

> One more, el-widgets

I think emacs-widgets is a good name, with ewidgets for short.

John

Re: The xwidget branch origin story

[joakim]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Michael Abrahams <miabraha@gmail.com> writes:
>
>> One more, el-widgets
>
> I think emacs-widgets is a good name, with ewidgets for short.

So, ewidgets in the source and emacs-widgets in documentation?

>
> John

-- 
Joakim Verona

Re: The xwidget branch origin story

[John Wiegley]

>>>>> joakim  <joakim@verona.se> writes:

> So, ewidgets in the source and emacs-widgets in documentation?

Sounds good!

John

Re: The xwidget branch origin story

[Andy Moreton]

On Sun 22 Nov 2015, John Wiegley wrote:

>>>>>> Michael Abrahams <miabraha@gmail.com> writes:
>
>> One more, el-widgets
>
> I think emacs-widgets is a good name, with ewidgets for short.
>
> John

Emacs already has lisp/widget.el and lisp/wid-edit.el with a set of
widget-* functions used by customize.

Any name using widget will lead to confusion - please try to find a name
that does not clash with an existing feature.

    AndyM

Re: The xwidget branch origin story

[John Wiegley]

>>>>> Andy Moreton <andrewjmoreton@gmail.com> writes:

> Emacs already has lisp/widget.el and lisp/wid-edit.el with a set of widget-*
> functions used by customize.

> Any name using widget will lead to confusion - please try to find a name
> that does not clash with an existing feature.

Andy makes an excellent point: "widgets" (without clarification) have a
precise meaning, so "Emacs widgets" vs. "emacs-widgets" would cause a great
deal of confusion.

We need another name for these interactive objects that can be inserted into a
buffer, whose functionality is not implemented by Emacs itself. Sort of
like... hosted components, gadgets?

John

RE: The xwidget branch origin story

[Drew Adams]

> > Emacs already has lisp/widget.el and lisp/wid-edit.el with a set of
> > widget-* functions used by customize.
> 
> > Any name using widget will lead to confusion - please try to find a name
> > that does not clash with an existing feature.
> 
> Andy makes an excellent point: "widgets" (without clarification) have a
> precise meaning, so "Emacs widgets" vs. "emacs-widgets" would cause a
> great deal of confusion.
> 
> We need another name for these interactive objects that can be inserted
> into a buffer, whose functionality is not implemented by Emacs itself.
> Sort of like... hosted components, gadgets?

That was my point as well.  I said:

  Since `xwidget' is misleading people, and the `x' doesn't help in
  any way, please just rename it.  But we also already have Emacs
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  code concerning widgets, so maybe try to come up with a name that
  ^^^^^^^^^^^^^^^^^^^^^^^
  is specific to these particular widgets or their use.
                 ^^^^^

Re: The xwidget branch origin story

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> That was my point as well.

A response ahead of its time, clearly. :)

John

Re: The xwidget branch origin story

[joakim]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>
>> Emacs already has lisp/widget.el and lisp/wid-edit.el with a set of widget-*
>> functions used by customize.
>
>> Any name using widget will lead to confusion - please try to find a name
>> that does not clash with an existing feature.
>
> Andy makes an excellent point: "widgets" (without clarification) have a
> precise meaning, so "Emacs widgets" vs. "emacs-widgets" would cause a great
> deal of confusion.
>
> We need another name for these interactive objects that can be inserted into a
> buffer, whose functionality is not implemented by Emacs itself. Sort of
> like... hosted components, gadgets?

To demonstrate my lack of naming skills:

- ele : emacs linking and embedding. But thats a bit short for a unique
prefix

- elec : emacs linking and embedding controls

- eniac : emacs native interactive advanced controls

I guess I'll stop now.

But I think I need to do a rename soon, and it would be some work to get
it right, so I would like to have some consensus on a name before I do it.

>
> John
>

-- 
Joakim Verona

Re: The xwidget branch origin story

[Iñigo Serna]

On 26 November 2015 22:16:38 joakim@verona.se wrote:
> To demonstrate my lack of naming skills:
> [...]

What about...
- emacs: emacs mechanisms for alternative control systems ?

Re: The xwidget branch origin story

[Andy Moreton]

On Tue 24 Nov 2015, John Wiegley wrote:

>>>>>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>
>> Emacs already has lisp/widget.el and lisp/wid-edit.el with a set of widget-*
>> functions used by customize.
>
>> Any name using widget will lead to confusion - please try to find a name
>> that does not clash with an existing feature.
>
> Andy makes an excellent point: "widgets" (without clarification) have a
> precise meaning, so "Emacs widgets" vs. "emacs-widgets" would cause a great
> deal of confusion.
>
> We need another name for these interactive objects that can be inserted into a
> buffer, whose functionality is not implemented by Emacs itself. Sort of
> like... hosted components, gadgets?

... unless the facilities offered by the new code on the xwidget branch
can be unified with the existing widgets package to provide a unified
interface so that the same user interface features are available on a
terminal or a graphical frame.

Of course I expect that that involves a great deal more work...

    AndyM

Re: The xwidget branch origin story

[Eli Zaretskii]

> From: joakim@verona.se
> Date: Thu, 26 Nov 2015 22:16:12 +0100
> Cc: emacs-tangents@gnu.org
> 
> To demonstrate my lack of naming skills:
> 
> - ele : emacs linking and embedding. But thats a bit short for a unique
> prefix
> 
> - elec : emacs linking and embedding controls
> 
> - eniac : emacs native interactive advanced controls
> 
> I guess I'll stop now.

I suggest to take a step back and ask: how are such features called
out there?  I think "embedded widgets" is on name, no?