Re: Automatic Qt bindings: status update

["Mauro Iazzi" <mauro.iazzi@...>]

2008/6/24  <syntheticpp@gmx.net>:
>
> -------- Original-Nachricht --------
>> 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.
>
> Yes, this is a disadvantage.
>
>> However the parsing work is done by the same code.
>
> Ah, I see, the parser folder.
>
>>
>> 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.
>
> You mean, it is not possible to redefine/overwrite a virtual function
> in e.g. Lua, but calling it from Lua is ok?

exactly.
also notice that as long as you use it in lua, you can redefine the
method so that any lua code will call the new one, but if you pass the
object to a C++ function it won't work. e.g. if you redefine the
QObject::event method, it won't be ever called from the main (C++)
loop, since the vtable of the object still points to the old version
of event.

To achieve this behavior, you need to derive the class and redefine
the functions so that they call Lua versions, which is what I do in
lqt. SWIG would need to do this in each language.



>
> struct A { virtual void foo(){}; };
> struct B : { void foo(){}; };
>
> b = new_B()
> b:foo()
>
> calls B::foo?
>
> Peter
>
>
>> 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
>> >>
>> >
>
> --
> Psssst! Schon vom neuen GMX MultiMessenger gehört?
> Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
>