[Kde-bindings] ruby bindings

[Richard Dale]

On Wednesday 30 April 2003 00:40, Ian Reinhart Geiser wrote:
> On Tuesday 29 April 2003 05:51 pm, Richard Dale wrote:
> > > i'd really like to just get on with apps. but,
> > > thats not going to work. swig and stuff like that
> > > appears to blow (excuse the pun). and afaik thereI=
> > > are no working ruby bindings other than those atm.
> > > though i might be wrong of course :)
> >
> > It shouldn't be too difficult to write a Qt smoke adaptor for ruby - that
> > is still the best way forward. Should we try and have a look at seeing
> > what's involved - I think so yes, so lets discuss it on this list..
>
> Lucky its undocumented and almost impossible to use.  Not as impossible as
> kalyputs but close ;)
Smoke documentation is now pretty well sorted - thanks Germain! I find the 
hardest part is following perl .xs code - I need to do a bit of revision 
about that - some of it looks just like assembler to me for now :(..

> There is the looks of an attempt at ruby bindings but it looks like they
> got as far as my SWIG based ones.  Unless you wrote this junk its unusable.
Yes, it wan't finished - although it didn't take long to generate most of the 
same output as SWIG. However, having done that I realised that there were too 
many problems with Nobuyuki Horie's SWIG approach because it doesn't handle 
overloaded methods, and I think he'd had to just hand fixup a some of them to 
get as far as he did.

> The plus side is from what I have seen from the swig bindings is that they
> preserve the inheritence structures, and do many of the messy up-down casts
> for you in python and TCL.  Slowly I have been building an interface set so
> that we can generate these bindings on the fly.  I have looked at the
> doxygen XML output and it looks promiseing, but it is quite busy to parse.
And all roads lead to XML it seems to me.. Do there need to be standard DTD's 
for parsed C++ code? How difficult is it to write XSLT stylesheets to 
translate between two different sorts? When Adam Treat first started saying 
what a good idea it was, and added an xml generation option to kalyptus, I 
couldn't see the point. But now I have repented, I see the light, xml is the 
one true way..

> Lastly I have almost completey worked out a library for bridgeing
> slignal/slots from C++ into code that provides introspection (pretty much
> very language out there today)  It takes 1 half written in C++ and the
> other half is written in the native language.  Not as automagical as I had
> hoped but its showing promise.
I don't like scripting languages to have to use C++ type signatures for 
connecting signals and slots, I think they should be hidden from a 
prototyping language like perl or ruby.

This:
Qt::Object::connect(fontComboBox, SIGNAL "activated(string)", textEdit, SLOT 
"setFocus()");

Rather than this:
Qt::Object::connect(fontComboBox, SIGNAL "activated(const QString&)", 
textEdit, SLOT "setFocus()");

..or maybe not. I assume PerlQt users haven't complained so perhaps it doesn't 
matter.

> In the end though, we all fall victim to lack of time, and the demand for
> this is just not big enough.  I think the other thing we like to ignore is
> the fact that KDE/Qt requires quite a bit of  C magic for DSOs to work.  To
> provide Python bindings is not that useful if you cannot provide a part
> loader  to load your fancy part.  At least from where I see it :P
>
> Im not sure what the answer is here.  Taj made it sound like he had
> something big brewing here (a new kdoc written in python) that will export
> to XML and use XLST to render to something.  Maby this is what we are
> waiting for and wanting?  I do not know, time and the coder who does it
> will though :)
Yes, that sounds interesting. Marco Ladermann has just checked in a juic 
utility written entirely in XSLT to generate java code from a .ui file (under 
qtjava/designer/juic). I would like to use that code as a basis for a full 
blown bindings generation system - it isn't so different generating java code 
from a .ui xml file compared with a C++ header derived xml file.

Once, you can seperate the parsing stage from the rendering, it means that you 
can choose to use either header parsers like kdoc, or object code 
introspection tools like Ashley's dumper for the front end .xml generation 
and it doesn't matter. And you should be able to combine the two, so that 
kdoc comments can be pulled out of the headers and mixed with code generated 
from analysing the object code.

-- Richard