Octave control via d-bus

[Patrick Noffke]

Greetings,

I would like to add the ability to exchange data between octave and the spreadsheet programs openoffice, kspread, and gnumeric.  Pedro Lucas (cc'd), the developer of QtOctave, suggested this to me when I asked him what I could do to help with QtOctave.  At first, I was looking at just openoffice, and at octave being the "master" and openoffice being the "slave."  That is, run a command in octave (maybe with a nice gui in QtOctave) to generate a spreadsheet (or writer document with table) from an octave array (I am aware of PyUNO and have experimented some with this).  But it seemed that it is more useful for the spreadsheet to be the master, since that gives the user control over the formatting.  I'm thinking something like the Matlab Excel Link, for those of you that know about this product.

All three spreadsheet programs are python scriptable, and you can react to events (e.g. changes in a cell that might be a parameter to an octave function, and require re-calling the octave function).

At a minimum, I want to do the following:
* SetMatrix (an operation that sets an octave workspace variable using contents from a spreadsheet).
* GetMatrix (an operation that retrieves an octave workspace variable and updates the spreadsheet contents).
* RunScript (an operation that runs an octave script with parameters from the spreadsheet and returning one or more arrays).

I thought about using a mechanism like Pedro uses with QtOctave (communicating via octave stdin/stdout, and passing data in temporary files).  This is not a bad option, and would meet all three of my goals.

But I also thought it would be nice to do the following:
* Add a debug interface (dbstep, dbcont, etc.)
* Connect the spreadsheet to an existing instance of octave.

And I also thought d-bus is taking hold with KDE and Gnome, so it is likely to be around for a while.  Plus there is python-dbus which would I could use to make the spreadsheets talk to octave.

I'm aware of an earlier post (Jan 2009), where d-bus was discussed, but it appears to have been left hanging:
http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-January/010201.html

The suggestion was to do the d-bus processing before the call to gnu_readline.  However gnu_readline blocks until there is user input, so it would not work as I have described.  There needs to be a separate dbus loop that can asynchronously peek/poke octave.

I was able to get the seeds of this happening with dbus-cxx (a C++ binding to libdbus, that uses signals and slots mechanism from sigc++ library).  Basically I used the "hello, world" client (the signal_emitter example of dbus-cxx), and put a slot in toplev.cc that prints the message sent by the client.

Now, I'm not sure of the best way to peek/poke octave, and I am hoping someone can provide some guidance.  I can send objects (i.e. matrices) via d-bus, but I have to do some work in telling d-bus how the data is transferred.  So I'm thinking to create a small-ish matrix class for the d-bus side, and I'll provide a means to translate to/from one of the Matrix classes in liboctave (e.g. FloatMatrix).  I tried following what happens after user input is read (hoping to find where the data goes), but I quickly got lost in lex code.  What is the best way to hook into the workspace variables?



Some dbus-cxx details:

* I've attached a diff of what I've done so far in order to build octave with dbus-cxx.  This is not patch-ready, but simply to facilitate review and discussion.  The signal_emitter example is also attached.
* I tried to model my changes after the code that detects whether GraphicsMagick++ is present.  That got me pretty far, but the last step I needed was to use DBUS_CXX_CPPFLAGS when compiling toplev.cc.  The only way I could see to do this was to use it for AM_CPPFLAGS in src/Makefile.am, line 31.  I'm not sure if this is correct.
* I found this page that shows how to create a dbus service, which would enable the dbus-daemon to launch octave if it is not running, or connect to an instance that is running.  I will attempt to follow this example for octave once I get data transfer working.
http://raphael.slinckx.net/blog/documents/dbus-tutorial
* I'm not sure what platforms this will not work with.  I'm hoping if everything is configured/built/installed with autotools, the compatibility issues will be minimized.  I will plan to compile out the dbus-code if dbus-cxx is not detected (probably by checking if HAVE_DBUS_CXX is defined).
* To use dbus-cxx, I had to use -std=c++0x as part of the CPPFLAGS.  It would not compile otherwise.  I like the simplicity of the dbus-cxx over libdbus (and the dbus project recommends not using libdbus directly, but rather one of the bindings), but if this has too many compatibility problems, I can look at other options.  Unfortunately, I think they are Qt or libdbus.  Not sure how everyone feels about Qt being a dependency of octave.  That may cause other compatibility issues though.  I won't really know until I try (if needed).
* Note that the slots to process dbus events could live anywhere.  I just started in toplev.cc to see if I could get the library working.  They belong in the best place to hook into octave workspace variables, wherever that may be.
* It makes sense to add some synchronization between dbus events and the main thread (that reads user input).  I can do that.  Do you have a suggestion?  I was thinking to start with a pthread mutex.

I appreciate any feedback.  I have been looking at octave code (in my spare time) for a few weeks now.  There is a lot there, so I may be completely missing a better, already existing, mechanism for doing this.  And there are probably side effects of my approach that I'm not aware of.  Please let me know if there's a better way or if I'm going to break something else.

Thanks for reading this far.

Kind regards,
Patrick

dbus-hello.diff
Description: Binary data

signal_emitter.cpp
Description: Text Data