lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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)

> 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?

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
> > > >
> > > >
> > >
> >
>