[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Qt-4.5 under LGPL and Lua bindings
- From: Mauro Iazzi <mauro.iazzi@...>
- Date: Sat, 17 Jan 2009 12:49:54 +0100
2009/1/17 Anders Backman <email@example.com>:
> I would be interesting to see if this (excellent start of a) framework could
> be generalized enough to be used for wrapping any C++ API to lua?
it is our goal to use lqt on any C++ library (and change the name,
then). We try to keep Qt specific things separated from the rest.
What misses now are mainly two things: downcasting and member
variables. All Qt classes have get/set methods, so it was not a big
issue. And in general few APIs rely heavily on dynamic_cast. But those
things should be done sooner or later.
> There is an external cpp2xml that does not? depend on QT.
In the sense that it works on any C++ file. It does link to Qt.
> The rest is more or less done with lua (except for the slot/signal stuff
> which has to be fed to moc), but shouldnt it be possible to extract what is
> core c++2lua and add the qtlua ontop of that?
> I have been using tolua++ for quite some years, and even if I like it a lot,
> I have always been bothered about the generation of the .tolua
> files...There is always a lot of handwork there, keeping namespaces,
> removing private etc...
> It would just be marvelous if this process could be more or less automatic.
> This framework proves that it is perfectly possible.
> Also, will the cpp2xml become LGPL when QT moves over that (brigher) side of
> the universe?
I usually prefer more liberal licenses, in fact the generator is MIT
licensed. However this is a tool and not a library so GPL should be
just fine. And even if Qt 4.5 will be LGPL, cpptoxml can be linked
against (and was developed using) Qt 4.3. I think we can wait for the
LGPL version to be widely available before switching. Peter, what do
> On Sat, Jan 17, 2009 at 2:29 AM, Mauro Iazzi <firstname.lastname@example.org> wrote:
>> Just to add a few comments to Peter's.
>> lqt is quite complete, but we need complex use cases. I have little
>> time to develop one myself. If anyone can provide us with feedback it
>> would be very useful for us.
>> Deriving from Qt classes is as simple as
>> w = QWidget()
>> function w:mouseEvent(e)
>> -- code
>> Almost every public function in the Qt manual should be present in the
>> bindings (automatic, so I do not really know) so that one is the main
>> reference you need. Conversion between arguments should be immediate.
>> The bindings automatically choose the version of a function that
>> matches the given parameters, eventually making use of default values.
>> non static methods are called with the colon syntax (or with an
>> explicit self argument).
>> adding a slot is done with
>> w:__addmethod(classname, signature, func)
>> test/t7.lua is the corresponding example. You can also see a simple
>> example using webkit in the same folder.
>> > One of the drawbacks of multi-platform UI toolkits is their bulk. Can
>> > you
>> > tell us the size(s) the lqt library(ies) on the three platforms?
>> on linux the stripped modules (not including qt objects) are:
>> 218K liblua.so
>> 1.6M libqtcore.so
>> 6.8M libqtgui.so
>> 579K libqtnetwork.so
>> 480K libqtopengl.so
>> 292K libqtscript.so
>> 442K libqtsvg.so
>> 355K libqtwebkit.so
>> 395K libqtxml.so
>> The biggest one is obviously the gui part. As you can notice the size
>> is almost the same of the original shared objects. Not surprising,
>> since mainly we have to generate boilerplate code for each class in
>> the api. I don't know the sizes on windows or OSX.
>> You also have to consider that a bunch of things are stored in the Lua
>> register, which leads to bigger memory consumption. Should not be an
>> issue on a modern desktop though.
>> Alexandre, is there any public source of libqtlua?
>> I did start a lua plugin for Kross, the new scripting system of KDE,
>> which in turn is compatible with QtScript. There are a few pieces
>> still missing. If I find time to finish that, it will allow for lua
>> scripting in applications like the KOffice suite and hopefully Amarok.
>> The code is in the KDE repository, in playground/bindings/kloss.
>> Since the two frameworks are similar it would be interesting to see
>> how you solved some of the problems I had.
> Anders Backman, CTO Algoryx Simulation AB
> Uminova Science Park, Box 7973, SE-907 19
> Umeå, Sweden
> email@example.com http://www.algoryx.se
> Cell: +46-70-392 64 67