Dia Language Bindings (2) (was: Re: Graph::ASCII::Dia)

[Hans Breuer <hans breuer org>]

On 24.03.2006 14:01, Aaron Trevena wrote:
> On 23/03/06, Lars Clausen <lars raeder dk> wrote:
> > Because nobody has found it worthwhile enough to make bindings for any
> > other language.  Dia is in no way, shape or form wedded to python, and
> > don't let Hans' refusal to provide bindings for other languages give you
> > that idea.  He made his bindings for his favorite language.  If you want
> > to make bindings for Perl or Ruby or Java or Fortran or Cobol or
> > whatever, we're cool with that, and would probably want to include it in
> > the distribution like the Python plugin is.
>
> If it's likely to get included it might be worth while I really don't
> want to have to maintain a fork or hard to add add-on seperately.
On 23.03.2006 17:50, Hans Breuer wrote:
> On 23.03.2006 14:39, Aaron Trevena wrote:
> > that actually be helpful in anyway towards a language independant API.
> My best guess on Dia's way for 'language independent API' or better
> bindability would be GObject:
After a little more thought [and about 3K lines of code ;) ] I have a
better offer:  Language Bindings done with the help of SWIG [1].

It not only supports Python and Perl but also about ten other languages

On 24.03.2006 14:01, Aaron Trevena wrote:
> I had a quick look at the perl embedding side, the main difficulty
> will be mapping all the objects and writing the c code to call perl
> that access objects through the perl/c api in order to provide a
> working plugin system.
>
> I guess that means splitting into two jobs - first a Perl XS wrapper
> for the Dia libraries,  and second a way to call perl that uses that
> wrapper from within Dia.
>
> The first involves a lot of digging around Dia, which will be very
> time consuming, even if I can use some of the python api as a map, but
> in itself won't be HARD, just a lot of work.
The first part should have become a lot less work and much easier
due to the new C++ API I've written to be wrapped by SWIG.

It has quite some advantages over the original C API cause:
 - it is fully documented [2]
 - the object orientation is in the API - not only in the code.
   So it is visible for SWIG and thus in the target language.
 - it hides the somewhat tedious implementation details of
   Dia's property API.
 - and it is small ...

... but powerful enough to execute quite some of the existing scripts.

Currently it gets only compiled and tested for Python on win32
with msvc. Yet there are are only about 200 lines of Python specific
code which should be simple to rewrite for someone reasonable proficient
in C++ and the desired target language.

Some SWIG knowledge can easily be acquired on the way ;)
In the .swig file there is some more Python specifc code, because SWIG's
typemaps template generation does not compile with msvc6. It should be
possible to write most of these in a generic way if one can rely on a more
capable C++ compiler (gcc 3.x or msvc-7.1).

> The second part will be trickier and that's where I'll be needing help.
The second part is IMO optional. As shown - just binding libdia (Object,
ObjectType, Renderer, Properties, Import- and ExportFilter ...) is enough
to do quite some nice things like importing and/or generating a diagram
and saving the result as another diagram.

Due to some limitation in Dia's current code base it is not yet possible
to read or write Dia's native format. But fixing this should be just
a matter of some refactoring - which I plan to do after the current release
is out of the door and I find some spare time.

Still the second part would make the bindings even more useful. I'd
split it again in two parts:

 - make objects written with the bindings callable by Dia's subsystems.
   This would allow to cover some more of existing (e.g. export filters)
   and some often requested features (e.g. make Dia(gram-)Object(s)
   implementable in a scripting language).
   At the moment I have no idea how to do this binding language
   independent.

 - integrate the scripting language with Dia's GUI i.e. run embedded.
   Again I currently see no way to do this language independent.

> Don't expect much any time soon though, I'll wait until at least the
> new version is stable, but if anybody else is interested in
> collaborating or helping, let me know.
As noted above improving bindability would involve some code changes
in the core. So it is not stability holding us back, but Dia is rather too
stable, the trunk was frozen when I started this a year ago and it was
again frozen when I picked it up again about a month ago.

BTW: the code did not rot too much because the wrapped API stayed almost
stable for a year.

Regards,
        Hans

[1] http://www.swig.org/
[2] http://hans.breuer.org/dia/bindings/index.html

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert