[Kde-bindings] Common work for Qt4 bindings

[Richard Dale]

On Saturday 10 September 2005 04:18, Eric Jardim wrote:
> 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.
I've put the KPresenter slides online here:
http://www.tipitina.demon.co.uk/KDE_Bindings.kpr

Also look for Ashley Winters two blogs about Smoke v2. He has suggested using 
the gcc translation unit dump for parsing. One .so file per class, rather 
than putting them all in one library. For the runtime he has suggested either 
using the Qt 4 moc format for introspection, but cover the whole api rather 
than just slots, signals, enums and properties. Or keep the xml from the 
translation unit dump and query it at runtime via XPATH. I prefer the first 
idea.

> 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" ;)
I'm not sure about this, I would be interested in what 'pythonish extras' you 
would like to add and see if they could still be done if the library was 
autogenerated.

> 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.
Yes, interoperation is useful even if there isn't a common library. And 
Sebastian Sauer's mail about scripting in Kexi sounds the sort of thing the 
could be used as a common framework.

> 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.
As far as I know the uic isn't dead, just re-written. You still either 
generate C++ code or read in the .ui file at runtime.

> 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.
Ouch! I'm not so sure. The PyQt/PyKDE and QtRuby/Korundum ones are about as 
complete and well maintained as any other bindings for any other toolkit.

> 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.
We mainly need to add C# to python, ruby, java, javascript and perl; then we 
have a pretty good selection in every KDE release.

> 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?
Roberto Raggi is writing a C++ parser and AST walker/symbol table framework 
for use in KDevelop for parsing code completion, class browser and a 
refactoring engine. My favourite option would be to use that one for 
kdebindings too, for parsing and code generation. We could write language 
bindings for the tree walker interface if we didn't want to do the code 
generation in C++.

-- Richard