2005/9/13, Richard Dale <<a href="mailto:Richard_Dale@tipitina.demon.co.uk">Richard_Dale@tipitina.demon.co.uk</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also look for Ashley Winters two blogs about Smoke v2. He has suggested using<br>the gcc translation unit dump for parsing. One .so file per class, rather<br>than putting them all in one library. For the runtime he has suggested either
<br>using the Qt 4 moc format for introspection, but cover the whole api rather<br>than just slots, signals, enums and properties. Or keep the xml from the<br>translation unit dump and query it at runtime via XPATH. I prefer the first
<br>idea.</blockquote><div><br>
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.<br>
 <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm not sure about this, I would be interested in what 'pythonish extras' you<br>
would like to add and see if they could still be done if the library was<br>autogenerated.</blockquote><div><br>
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.<br>
 </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As far as I know the uic isn't dead, just re-written. You still either<br>generate C++ code or read in the .ui file at runtime.
</blockquote><div><br>
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. <br>
 <br>
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.<br>
<br>
</div> <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> What is being done right now in sense of common work?<br>Roberto Raggi is writing a C++ parser and AST walker/symbol table framework
<br>for use in KDevelop for parsing code completion, class browser and a<br>refactoring engine. My favourite option would be to use that one for<br>kdebindings too, for parsing and code generation. We could write language
<br>bindings for the tree walker interface if we didn't want to do the code<br>generation in C++.<br></blockquote></div><br>
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.<br>
<br>
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 ;)<br>
<br>
[Eric Jardim]<br>