[Kde-bindings] Common work for Qt4 bindings

[Eric Jardim]

Hi,

I just finished reading Richard's article: 
http://wiki.kde.org/tiki-index.php?page=Language+Bindings+Talk
and realised that we have a lot of points in common. 

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.

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.

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" ;)

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.

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.

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.

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.

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.

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:
http://www.gccxml.org/HTML/Index.html

There is also the Boost.Spirit project, that is a very interesting way of 
creating parsers (with c++ templates):
http://spirit.sourceforge.net/

There is another project called synopsis, that is used for doc generation, 
but have bigger goals:
http://synopsis.sourceforge.net/

Well, maybe I am talking too much ;)
What do you think of it. 
What is being done right now in sense of common work?

Thanks,

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20050909/7f6f85cb/attachment.html>