[Kde-bindings] Common work for Qt4 bindings

[Eric Jardim]

2005/9/13, Richard Dale <Richard_Dale at tipitina.demon.co.uk>:
> 
> 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.


I'll look at it. As I say, it looks like this is the approach gccxml uses. 
There is also a tool called pygccxml that is used to ease gccxml use. The 
same guy implemented a tool called py++ (pyplusplus) for generating 
Boost.Python code from pygccxml output.


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.


Well, we can add some tricks. But manual generation is good for 
studing/understanding (I am new at it). I am seriously thinking how 
python-qt4 would be automatic generated.

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 say it is "dead" in ways it is not necessary anymore. It is there for some 
people who thinks they "need" it. Well, everybody got their reasons. 

But for interpreted languages, dynamic ".ui" is just fine and is ready for 
*all* languages thru QFormBuilder. If the guy want's to create uic like, 
they might create one for each language (pyuic, rbuic, pluic, ...). That's 
the point.

 
> 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++.
> 

Sounds very interesting. It is good that this parser is made *separate* from 
KDevelop. He is probably going to support Qt specifics like Q_PROPERTY and 
all.

How is the progress of this parser? Where can I find it? Sorry for asking, 
but I am not part of the KDE team, well, not yet ;)

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