Hi,<br>
<br>
I just finished reading Richard's article: <br>
<a href="http://wiki.kde.org/tiki-index.php?page=Language+Bindings+Talk">http://wiki.kde.org/tiki-index.php?page=Language+Bindings+Talk</a><br>
and realised that we have a lot of points in common. <br>
<br>
He is right when he says that we have enough information in the C++
headers, but we have not a smart C++ parser to generate everything to
you. And that manual generation is not good if it will bring a lot of
headache.<br>
<br>
On the other hand, I don't think Smoke will solve everyones problem,
but a "smart" C++ parser, that generate a intermediate XML (or some
descriptive structured data), that is common for all bindings would be
good for everyone, including Smoke.<br>
<br>
The main problem is that each language has each own need, and being
very general would lead us to create boring bindings. The bindings
needs to be attractive to each bind language. Python binding need's to
be "pythonic", Ruby bindings needs to be "rubish" ;)<br>
<br>
What I am saying is, intead of just creating a super-library (Smoke) we
could create some rules that each binding should follow, in term it
still get usable not only for one binding, but for other things also.<br>
<br>
In my case, I expect my Python extended QObjects to work back with
embedded C++ code, and still be integratable with QtDesigner. This
would avoid us to create new "QtDesingers". Besides, we must face that
"uic" is *dead*. We now have QFormBuilder that acts like libglade for
GTK. But, differetly, QFormBuilder can be extendend to generate our
extended bindings objects. And don't forget about (the evil) threads.
People love them, even when they don't what they are doing.<br>
<br>
I still don't now what would be the definitve solution for this, but if
we don't do it now and do it right, people will not use it. One of KDE
weakness is poor binding. I admit Gnome bindings are not perfect, but
are much better that KDE's.<br>
<br>
An interesting thing to do is a survey of the "bindable" languages and
needs of each of them. With this, we can think better how Smoke would
be like, good for everyone. If not, just a few will use it and
everybody will loose.<br>
<br>
That's what I am saying, we have to find this "optimum point" for
everyone. I think the smart C++ parser, that recognise Qt macros
(Q_PROPERTY, Q_INTERFACE, Q_CLASSINFO, Q_ENUM, ...) would be a start
for everyone, with or without Smoke.<br>
<br>
I know that exists a c++ parsers called "gccxml" but it is not a
complete parser (it does not read templates). But maybe it is a start:<br>
<a href="http://www.gccxml.org/HTML/Index.html">http://www.gccxml.org/HTML/Index.html</a><br>
<br>
There is also the Boost.Spirit project, that is a very interesting way of creating parsers (with c++ templates):<br>
<a href="http://spirit.sourceforge.net/">http://spirit.sourceforge.net/</a><br>
<br>
There is another project called synopsis, that is used for doc generation, but have bigger goals:<br>
<a href="http://synopsis.sourceforge.net/">http://synopsis.sourceforge.net/</a><br>
<br>
Well, maybe I am talking too much ;)<br>
What do you think of it. <br>
What is being done right now in sense of common work?<br>
<br>
Thanks,<br>
<br>
[Eric Jardim]<br>