[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Automatic Qt bindings: status update
- From: syntheticpp@...
- Date: Tue, 24 Jun 2008 10:02:49 +0200
-------- 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?
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