[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Automatic Qt bindings: status update
- From: "Mauro Iazzi" <mauro.iazzi@...>
- Date: Mon, 23 Jun 2008 19:46:48 +0200
Yes, I know those projects, however I thought they weren't completely
fit to my goals. In fact I plan to create a binding generator for
arbitrary C++ code, not only Qt. For this reason I don't want to need
a typesystem description, since I would need to write one for every
other library.
However the parsing work is done by the same code.
SWIG has one big disadvantage which is that it cannot define virtual
functions (i.e. you can't redefine the virtual functions from the
target language). But it would surely be very useful for all the
libraries whose API don't rely on virtual functions.
Thank you for the interest,
mauro
2008/6/23 Peter Kümmel <syntheticpp@gmx.net>:
>
> Mauro Iazzi wrote:
>>
>> Hi all, I have changed much in my Qt bindings for Lua since last time I announced then,
>> so here is a little status update. For a bunch of reasons, lqt has been rewritten from
>> scratch, so it is actually a completely new binding generator.
>>
>> As the previous version, this is not complete nor bug-free nor well tested. It is
>> probably less feature-rich than the previous one. The main improvement, however, is
>> that it no more depends on GCC-XML. This means that it should be a lot more portable
>> than before.
>>
>> The bindings are generated in two steps. A C++ parser (based on the one originally
>> written by Roberto Raggi for KDevelop) parses any code which describes the API (a
>> standard C++ header) and produces an XML description of it. Then a lua script generates
>> the actual C++ code. This generated code defines wrappers for the functions that need
>> one and subclasses that redefine virtual functions, so that Lua functions can be called
>> as virtual members.
>
>
> Do you know the project QtScript-Generator
> http://labs.trolltech.com/page/Projects/QtScript/Generator
> at Trolltech/Labs?
>
> It adapts the tool which generates the Qt java binding code (QtJambi)
> http://doc.trolltech.com/qtjambi-4.4/html/com/trolltech/qt/qtjambi-generator.html
> to Trolltech's javascript implementation, QtScript.
>
> The typesystem mapping is stored in xml.
> http://doc.trolltech.com/qtjambi-4.4/html/com/trolltech/qt/qtjambi-typesystem.html
>
> I assume it is not that hard to add Lua support, especially because
> there are tested xmls for all Qt libraries.
>
> Trolltech/Labs projects are GPL but
> "The generated code has the same license as the API it binds."
> http://trolltech.com/developer/task-tracker/index_html?method=entry&id=213857
>
>
>>
>> Actually, the generator does that for *any* function and class it finds, where possible
>> (e.g. when those classes or functions are not private etc..). It can load filters that
>> forbid to bind some of those functions or classes. However I put some effort in
>> ensuring it only tries to bind what is actually public. Eventually, one should be able
>> to feed it with a header and retrieve the binding as-is.
>>
>> There is the possibility of specifying how some types are manipulated. For Qt bindings
>> this means that QPoint and QRect are treated as 2 or 4 numbers respectively, and
>> QByteArray is mapped into a normal string (QString is a userdata instead).
>>
>> Enums are mapped into the corresponding strings. As another example of custom type
>> definition, QFlags (a template which defines a bitmask of OR-ed enum values) are mapped
>> into tables of these strings.
>>
>> A special class is generated, which has one slot defined for each signal signature
>> found. Whenever these slots are called, they call callbacks which can be defined from
>> Lua.
>>
>> All these features make the binding quite usable. Ihave been able to implement the
>> first few tutorials from the Qt docs. The latest snapshot can be downloaded from http://repo.or.cz/w/lqt.git Simple build instructions are included.
>>
>> Possible future improvements, apart from polishing and documenting the code, may be
>> generating SWIG or tolua++ interface files, so that the bindings rely on frameworks
>> that are more stable and clean than the current one.
>
> Generating SWIG interface files would we fantastic! Then, by simply writing
> one binding (agains SWIG) you add all the languages supported by SWIG.
> I assume, then other people than Lua users are interested in your project.
>
>
> Peter
>
>
>> I hope someone is interested, comments and feedback are obviously welcome. Cheers,
>>
>> mauro
>>
>