Re: Updated lqt for Qt 5 and Lua 5.2?

[Michal Kottman]

On 17 September 2012 11:45, sergei karhof wrote:
> Hi Michal,
>
> will there be an updated lqt for Qt 5 and Lua 5.2?

Hi, unfortunately I didn't even have time to update lqt for Qt 4.8
(threading changes cause major issues with lqt, re-design is pending).
I did not even try running the generator on Qt 5.

Lua 5.2 also brings some issues I didn't deal with yet, though the API
changes were minimal and it "should work" (no promises though).

As of now, the supported (tested working) combination is Qt 4.7.4 and
Lua 5.1. Unfortunately I do not have the time to upgrade lqt anymore
(at least not until winter). Should anyone want to take up
maintenance, any help is appreciated.

Michal

[Michal Kottman]

On 17 September 2012 12:09, sergei karhof wrote:
> Thanks for your reply, Michal.
>
> Actually the Qt methods that I was planning to use are very few:
> basically file I/O methods, string processing and very basic GUI
> functions like text editbox, buttons, etc. In all, a very small subset
> of QtCore and QtGUI.
> Do you think that there might be a good chance that these methods
> could already be supported and work out-of-the-box with the present
> lqt (again: for Qt 5 and Lua 5.2), or do you expect any specific
> problem/complication?
>
> Thanks again

If you do not require specific functionality, you could in theory
blacklist the classes that cause compilation problems. The file is
located in generator/qt_internal.lua [1].

If there are any problems during compilation with specific classes you
do not need, just edit this file and add the classes those classes.
They will be ignored during the binding process.

The upgrade to Lua 5.2 should be straight-forward, if not, I may take
a look at it if there are problems...

[1] https://github.com/mkottman/lqt/blob/master/generator/qt_internal.lua

[Michael Kirsch]

I don't know if you noticed this since you didn't reply:

 https://groups.google.com/forum/?fromgroups=&pli=1#!topic/lqt-bindings/YGBs2weiTKs

Not sure  if it will be used, and it still has a lot of errors when given the entire QtCore library, but it's probably fixable. But anyway, it works and is *much* simpler than lqt. And the way it does OOP from the Lua side is much cleaner, almost exactly the way you would do it in pure Lua.

[Michal Kottman]

I've seen your attempt, and it seems that it works fine, which is
great. I'm not sure if you have seen the Lua mailing list lately,
regarding the option of cross-compilation, in which typelibs (in this
case your XML) are not a great idea, because they usually do not
capture the details of the target platform (some things may be
missing, etc.).

The QMetaObject was never meant to be accessible from Lqt, so it is
ignored. Quite a LOT of little tweaking went into lqt regarding
choosing what features to keep and what to ignore :)

[Michael Kirsch]

On Monday, September 17, 2012 10:47:28 AM UTC-4, Michal Kottman wrote:

I'm not sure if you have seen the Lua mailing list lately,
regarding the option of cross-compilation, in which typelibs (in this
case your XML) are not a great idea, because they usually do not
capture the details of the target platform (some things may be
missing, etc.).

I don't really understand. And without the XML, how else would you know what classes/functions to bind? 

[Michal Kottman]

On 17 September 2012 17:07, Michael Kirsch <mkirs...@gmail.com> wrote:
> I don't really understand. And without the XML, how else would you know what
> classes/functions to bind?

I guess I misunderstood, I thought you were generating the classes at
runtime from the XML description, whereas Lqt uses the XML description
at compile-time, which means that the binding is suited exactly to the
framework used on the target machine.

[Michael Kirsch]

On Monday, September 17, 2012 11:11:04 AM UTC-4, Michal Kottman wrote:

I guess I misunderstood, I thought you were generating the classes at
runtime from the XML description, whereas Lqt uses the XML description
at compile-time, which means that the binding is suited exactly to the
framework used on the target machine.

No, the way it works it with 2 scripts: the first one takes the XML, the blacklist, and the template list and converts it into a Lua table formatted file that says what things to bind, their C++ names, and where to put them in Lua. The second script takes this an converts it into a C++ file, which is the finished source code of the module.

[Michal Kottman]

This is, in essence, what the current lqt does :) Although it is in
dire need of re-write. There is a lot of know-how in the current
codebase (how to handle virtual methods, how to handle custom Qt
signals/slots, enums, custom getters and setters for public members,
...). Should you want to continue with your project and need to ask
anything, I will try to answer how it is implemented currently in lqt.

[Michael Kirsch]

On Monday, September 17, 2012 11:25:04 AM UTC-4, Michal Kottman wrote:

This is, in essence, what the current lqt does :) Although it is in
dire need of re-write. There is a lot of know-how in the current
codebase (how to handle virtual methods, how to handle custom Qt
signals/slots, enums, custom getters and setters for public members,
...). Should you want to continue with your project and need to ask
anything, I will try to answer how it is implemented currently in lqt.

Currently it doesn't handle reimplementing virtual methods from Lua at all (that's something I only plan in doing if it gets working), same with fields/properties. I also haven't thought about signals/slots because I think that can be done later, and I don't know of a place to learn how they work. But I do have two big problems right now:

First, how to know if a class is copyable?

Second, many functions in Qt have different overloads for different number types in C++. Lua has only one number type. So whatever overload is checked first will be used, which can cause loss of precision. What would be a good way to fix that?

[Michal Kottman]

On 17 September 2012 18:29, Michael Kirsch <mkirs...@gmail.com> wrote:
> On Monday, September 17, 2012 11:25:04 AM UTC-4, Michal Kottman wrote:
>>
>> This is, in essence, what the current lqt does :) Although it is in
>> dire need of re-write. There is a lot of know-how in the current
>> codebase (how to handle virtual methods, how to handle custom Qt
>> signals/slots, enums, custom getters and setters for public members,
>> ...). Should you want to continue with your project and need to ask
>> anything, I will try to answer how it is implemented currently in lqt.
>
>
> Currently it doesn't handle reimplementing virtual methods from Lua at all
> (that's something I only plan in doing if it gets working), same with
> fields/properties. I also haven't thought about signals/slots because I
> think that can be done later, and I don't know of a place to learn how they
> work. But I do have two big problems right now:
>
> First, how to know if a class is copyable?

In Qt, this is relatively simple - everything is copyable, EXCEPT
those classes that have *Private members.... Or at least this is what
I remember. I did quite a lot of bashing on C++ to get the behavior I
wanted of lqt. The relevant code is around
https://github.com/mkottman/lqt/blob/master/generator/classes.lua#L327
- simply stated, for those situations that do not have a copy
constructor explicitly stated, and are eligible for copy construction,
I will generate a copy constructor so that relevant code can be
generated.

> Second, many functions in Qt have different overloads for different number
> types in C++. Lua has only one number type. So whatever overload is checked
> first will be used, which can cause loss of precision. What would be a good
> way to fix that?

This was handled by Mauro Iazzi before me - the relevant code is here
- https://github.com/mkottman/lqt/blob/master/generator/classes.lua#L648
. Essentially the typesystem is a map of types C++ -> Lua, where the
basic numeric types are mapped in
https://github.com/mkottman/lqt/blob/master/generator/types.lua#L84 .
Each type has associated "defect", where defect(char) > defect(short)
> defect(int) > defect(long). When multiple overloaded methods have
the same Lua signature, the defects are counted, and the one with
smallest defect is chosen. For example, method(char), method(int) and
method(double) all have Lua signature method(number), so only
method(double) is chosen because of smallest defect (0).

[Michael Kirsch]

On Monday, September 17, 2012 12:42:28 PM UTC-4, Michal Kottman wrote:

In Qt, this is relatively simple - everything is copyable, EXCEPT
those classes that have *Private members.... Or at least this is what
I remember. I did quite a lot of bashing on C++ to get the behavior I
wanted of lqt. The relevant code is around
https://github.com/mkottman/lqt/blob/master/generator/classes.lua#L327
- simply stated, for those situations that do not have a copy
constructor explicitly stated, and are eligible for copy construction,
I will generate a copy constructor so that relevant code can be
generated.  

I think I figured it out by checking the constructors. 

 

This was handled by Mauro Iazzi before me - the relevant code is here
- https://github.com/mkottman/lqt/blob/master/generator/classes.lua#L648
. Essentially the typesystem is a map of types C++ -> Lua, where the
basic numeric types are mapped in
https://github.com/mkottman/lqt/blob/master/generator/types.lua#L84 .
Each type has associated "defect", where defect(char) > defect(short)
> defect(int) > defect(long). When multiple overloaded methods have
the same Lua signature, the defects are counted, and the one with
smallest defect is chosen. For example, method(char), method(int) and
method(double) all have Lua signature method(number), so only
method(double) is chosen because of smallest defect (0).

That seems good, I implemented it.

Anyway, it now compiles the bindings for almost all of QtCore. It still seems to have some Lua stack-related errors that make it crash while loading, though. I might try to fix that, and I'll probably put in on my GitHub fork of lqt then.

[Michael Kirsch]

I decided to just push it the way it is for now:

https://github.com/MTK358/lqt

[Michael Kirsch]

So, it's almost completely working now, even with QCoreApplication and connecting slots to Lua functions (but it doesn't pass any args).

Now my problem is how to add other modules (such as QtGui) that work with the existing QtCore module?

[Michal Kottman]

This is handled by using dependencies - at the end of CMakeLists.txt,
there is a list of modules to bind and their dependencies. When the
binding for a module is created, the XML is generated from the include
files and parsed. Types from dependent modules are read in [1], so
that the typesystem knows about them, but they are later ignored (as
they do not need to be generated again). After each binding, the
generator spits out classes that it bound, so that dependent modules
can read it back in.

[1] https://github.com/mkottman/lqt/blob/master/generator/generator.lua#L138

[Michael Kirsch]

Now I get errors when I load a Qt module that depends on another, because it can't see the functions in the other. How do i fix that?

Also, a lot of classes have private destructors, what does that even mean, and how do I work around it?

[Michael Kirsch]

On Saturday, September 29, 2012 7:04:24 AM UTC-4, Michael Kirsch wrote:

Now I get errors when I load a Qt module that depends on another, because it can't see the functions in the other. How do i fix that?

Also, a lot of classes have private destructors, what does that even mean, and how do I work around it?

I forgot, I still have another question:

Is it possible to receive a signal and get the arg types at runtime so I can pass them to Lua?