Re: Automatic Qt bindings for Lua

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

On 11/09/2007, Ariel Manzur <puntob@gmail.com> wrote:
> On 9/11/07, Mauro Iazzi <mauro.iazzi@gmail.com> wrote:
> > On 11/09/2007, Ariel Manzur <puntob@gmail.com> wrote:
> > > On 9/10/07, Mauro Iazzi <mauro.iazzi@gmail.com> wrote:
> > > > Given that much has changed between 4.1 and 4.3, I did not assume it
> > > > could work. The fact is that it is done with tolua++ which is a great
> > > > tool, if you control the source to be bound or it is quite small.
> > > >
> > > > The fact is that it requires some files (pkg) which must describe the
> > > > library code to tolua++. I don't know how those files were obtained
> > > > for Qt 4.1. but (miracles aside) they will not work with Qt 4.3.
> > > > Chances are that they were tweaked by hand (I _really_ don't know) and
> > > > seem not mantained anymore.
> > >
> > > As far as I know, the latest code on the SVN does compile with qt4.3
> > > (tested with qt-x11-opensource-src-4.3.0 aparently). Of course the
> > > bulk of the interface is not hand-tweaked (it was something like 15000
> > > methods for the whole thing), but some tweaking is needed to add
> > > convenient things (like transparent qvariants, stuff like that).
> > > But yeah, the API I have is pretty old..
> >
> > wonderful, thanks for all the information.
> >
> > I didn't really think that Qt API was so consistent between 4.1 and
> > 4.3. It's very good that it works with 4.3.
>
> yeah, basically there's a ton of missing stuff from qt4.3..
>
> > I knew that those files weren't generated by hand. They were indeed a lot :)
> > I just didn't know the amount of hand work involved in generating
> > them. It could range from zero to a big amount. The nearest to zero,
> > the easiest to regenerate them in case of API break from Qt.
>
> Most of the work was to put together the templates, which seem pretty
> stable.. Those are in separate pkg files, done by hand. My main
> concern when upgrading was the conditional building depending on the
> version.. I considered having an api for each major version within 4.0
> (4.1, 4.2, etc), and keep it compatible with all the minor versions..
> but I never got the time to maintain it.
>
> > > > My code uses gccxml, which is a backend (frontend) of gcc which
> > > > exposes the internal gcc representation of the code as an XML tree.
> > >
> > > how much does the parser depend on the 'Expat' library you mention on
> > > the original mail? can it be done using one of the 'pure-lua' parsers
> > > available out there?
> >
> > it depends just on having the tree structure similar to what luaexpat
> > does. It seemed quite a standard choice, looking in the wiki.
> >
> > the code using it is actually:
> >
> >   if not self.tree then
> >     local xmlf = io.open(filename, 'r')
> >     local xmls = xmlf:read('*a')
> >     xmlf:close()
> >     self.tree = lxp.lom.parse(xmls)
> >   end
> >
> > then every other function uses that tree. I think that it would not be
> > hard to put any other parser in place of expat, given some
> > restructuring of the tree into the same format as luaexpat. Speed
> > could suffer, but I don't care for now.
> > If you have a better suggestion, I'll be glad to hear it. Pure-lua
> > parsers would eliminate a requirement, so are welcome.
> >
> > I actualy thought It would be fine to produce automatically the pkgs
> > for tolua++, but I did not want to add another layer to the process.
> > My (badly named) common_bind.?pp files have probably the same
> > functions of the standard tolua++ headers, and probably duplicate much
> > of the functionality. Even if I didn't want to use tolua++, I could
> > have used those for common functions, but that wasn't so much work...
>
> Actually I was thinking about something like that.. Adding a way to
> input xml files into tolua (something like "$xfile"), that would get
> converted into 'pkg format' on the fly (the easiest and ugliest way I
> can think to hack it ;). It would probably be a diferent
> implementation, but I was wondering how different the library is from
> the pure-lua approach (so far I've only used Roberto's 'classic
> lua-only version' I found here: http://lua-users.org/wiki/LuaXml)
>

Oh, I didn't know that was the 'classic version'. Does it work as the expat one?

> > So, thanks again for the explainations above and I hope I've answered
> > to your questions,
>
> Thanks.. I was also curious (I'm going to check out the code
> eventually ;) about the way you handled connecting signals/slots from
> lua.. do you have any notes about that? Does gccxml tell you about the
> 'signals' and 'slots' labels, or do those go away with the
> preprocessor?
>

lqt has no builtin method for reflection of slots/signals in
particular, but they are just plain functions in C++, and are
addressed by connect using strings. QObject::connect gets
automatically bound in Lua and accepts one QObject, one string, one
QObject and one string in this order. It works (as in the demo...) if
fed the appropriate strings.
So I had nothing special to do to handle signal/slots.

The reflection made by Qt's moc is bound too, so that can be
exploited, provided you can handle QList<QByteArray> in Lua. I see no
reason for it not to work, as gccxml treats it as just another class,
though I have not tried. In that case, One could inspect the classes
slots and signals using that.

I  just remember that I only tried to call explicitly slots, but not
signals (which are functions made by moc). I think it will just work,
but I don't know, to be honest.

The labels are stripped out, because gccxml is just gcc, so only
treats pure C++ (and those labels fade when preprocessed).

if you really will see the code, tell me your observations, I'll be
glad to hear them. Because I have not a versioning system or public
repository, the code could change without advise. I already have a
bunch of changes locally that I didn't put in the tarball...

mauro

> Thanks..
>
> Ariel.
>
> >
> > mauro
> >
> > >
> > > Ariel.
> > >
> > > > Then my generator processes it and makes the bindings. Ideally, if I
> > > > update to Qt 4.4, I just have to run it again. It would be a forever
> > > > up to date binding. I think it was worth trying whether it was
> > > > feasible.
> > > >
> > > > I'm quite happy of the results. They are almost usable for basic needs.
> > > >
> > > > mauro
> > > >
> > > > On 10/09/2007, Carlos Augusto Teixeira Mendes <cmendes@k2sistemas.com.br> wrote:
> > > > > Have you checked LuaQt by Ariel Manzur?
> > > > >
> > > > > It's pretty complete and works well.  Don't know if it has been updated
> > > > > recently. The version we are using is for Qt 4.1.x (latest version is
> > > > > 4.3.x).  Beside some small corrections it worked fine for us.
> > > > >
> > > > > cheers,
> > > > > Carlos Augusto.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: lua-bounces@bazar2.conectiva.com.br
> > > > > > [mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Mauro Iazzi
> > > > > > Sent: Saturday, September 08, 2007 2:46 PM
> > > > > > To: lua@bazar2.conectiva.com.br
> > > > > > Subject: Automatic Qt bindings for Lua
> > > > > >
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > in the past months I used some of my spare time to make Qt bindings
> > > > > > for Lua. I now have a working simple program to show how far I've got,
> > > > > > and a little screencast showing off some capabilities.
> > > > > >
> > > > > > The program is here:
> > > > > > http://linuz.sns.it/~iazzi/lqtutorial.tar.gz
> > > > > >
> > > > > > The screencast is here:
> > > > > > http://linuz.sns.it/~iazzi/tutorial.ogg
> > > > > >
> > > > > > To compile use
> > > > > > qmake
> > > > > > make
> > > > > > ./lqtutorial
> > > > > >
> > > > > > Users of Debian-based systems should be fine using the
> > > > > > lqtutorial.pro.debian file.
> > > > > >
> > > > > > The bindings are autogenerated using the output ogf GCCXML. I included
> > > > > > the bindings for just a few basic classes. I will try and package the
> > > > > > generator in a few days. The generator is written in less than 1000
> > > > > > lines of Lua code, and makes use of the Expat library for parsing XML.
> > > > > >
> > > > > > Among the best hings there is the fact that I did not have to touch
> > > > > > any generated file by hand. They just worked.
> > > > > >
> > > > > > Moreover, they are completely modular, so that I can have the bindings
> > > > > > for only few classes that I actually need. This provides a lot of
> > > > > > modularity, which could be exploited to make very small programs.
> > > > > >
> > > > > > Finally, the generator has only be used on Qt, but is totally generic,
> > > > > > and can be used on any C++ code, although I don't know how well it
> > > > > > would understand some complex features of C++ (as deeply nested local
> > > > > > classes, barbaric use of templates and such).
> > > > > >
> > > > > > I strongly hope that this is of some interest to someone.
> > > > > > Cheers,
> > > > > >
> > > > > > mauro
> > > > > > No virus found in this incoming message.
> > > > > > Checked by AVG.
> > > > > > Version: 7.5.485 / Virus Database: 269.13.13/998 - Release Date:
> > > > > > 9/10/2007 8:48 AM
> > > > > >
> > > > > No virus found in this outgoing message.
> > > > > Checked by AVG.
> > > > > Version: 7.5.485 / Virus Database: 269.13.13/998 - Release Date: 9/10/2007
> > > > > 8:48 AM
> > > > >
> > > > >
> > > >
> > >
> >
>