[Dev] Fwd: XUL-based Integra GUI

[Stephen Sinclair]

On Tue, Dec 16, 2008 at 5:16 PM, Jamie Bullock <jb at integralive.org> wrote:
>
> Hi Steve,
>
> It's really great to see this stuff in svn now. I don't think i'd fully
> appreciated the extent of the libIntegra 'integration' (sic) until I
> read your commit messages -- it's very satisfying to see this.

Cool!  A lot of the commit messages are just restyling various
portions of the GUI to make things fit together properly--probably
someone (a web developer?) with better CSS-fu could do a better job.
Anyways I thought it would be better to use a series of commits rather
than just dumping the whole thing in one shot, so that specific
changes can be reviewed.

I probably need to give a few more comments about the libIntegra integration:

When I started off with it, I was a bit confused about how to "talk"
to libIntegra.  I based it off my LibLo-based XPCOM module, which
allows sending and receiving OSC messages with JavaScript, but then I
thought it would be good to actually link libIntegra into the
application directly.  So I started creating a libIntegra XPCOM
bridge.  However, after a previous discussion where I asked about the
appropriate method of communicating with libIntegra (if you recall, I
asked about whether it had a C API), we sort of concluded that the
proper libIntegra protocol is OSC for now.  So I left the libIntegra
XPCOM component in the repository, but it's unfinished.

The JavaScript itself though also has a libIntegra API.  (It's in
libIntegra.js.)  You'll see that I tried to reproduce the libIntegra
OSC API with JavaScript functions.

There are two different versions of the libIntegra JavaScript class.
One sends and receives messages over OSC, the other is called "dummy".
 They are basically just two JS objects that implement the same
interface, which is selected on startup.

The OSC interface is not complete, but it is able to instantiate
modules, and get back the "/loaded" message.

So, both these libIntegra interfaces need work.  But, it would be
perfectly feasible to replace the OSC calls with calls to a libIntegra
XPCOM bridge, or by XMLHttpRequest calls.  The JS interface would
remain the same.

The GUI doesn't implement much functionality, so it doesn't cover the
same ground as the Max/MSP GUI for now.  The module boxes could be
done in canvas or SVG, but for now I did it using <div> elements.

I'll try to add some documentation soon on how to actually build the
OS X app bundle.  Building the OSC XPCOM component under OS X wasn't
really straight-forward, but hopefully it won't need to be done very
often. :)  It's the only "compiled" part of the program, and generally
won't need to change much.  (It could certainly be improved in various
ways however.)  But in the meantime I suggest just copying the files
"OpenSoundControl.dylib" and "IOpenSoundControl.xpt" from the binary
release I posted earlier.

On Linux it's quite easy to get it going, you just need some specific
packages installed.  I haven't even tried on Windows yet, but I think
it wouldn't be too hard if you're willing to fight with Visual Studio.
 There are projects like SongBird which show how you can do a
cross-platform XULRunner-based application.  (In fact I built the app
bundle by copying a SongBird release and replacing the Resources
folder with the Integra code.)


Steve