Re: lqt: Qt bindings update

lqt_shell_agx_LQT_Vec3 (lua_State *l, double constarg1[3]) : agx::Vec3(arg1), L(l) { lqtL_register(L, this); }

Where constarg of course should be const arg1[3]

Problem comes from line 578 in generator.lua

cline = cline .. ', ' .. argument_name(a.xarg.type_name, 'arg'..i)

should be

cline = cline .. ', ' .. argument_name(a.xarg.type_name, ' arg'..i)

#2 I emailed about another problem previously:

> Now I added -i ${BINDING_HEADER}/${BINDING_HEADER}
> Which generates:
>
> #ifndef LQT_HEAD_agxStream_LQT_EndOfArchiveException
> #define LQT_HEAD_agxStream_LQT_EndOfArchiveException
> #include "lqt_common.hpp"
> #include "libname/libname" <<<<
> #include "lqt_qt.hpp"

Mario wrote> I assume this is the behaviour you wanted, correct?

Yes, but the problem is below!

> // But then this libname depends on another namespace which is then tried to
> be included with:
> #include <otherlib>
^^^^^^^^^^

Should be

#include <otherlib/otherlib>

Or at least there should be a way to get this.

Because if I have "otherlib/otherlib" above, then what is the reason for having <otherlib> a few lines below?

I dont want to "open" up namespace directories, for example for openscenegraph, it would be devistating to do

-I include/osg

-I include/osgDB

-I include/osgViewer

etc...

Sometimes there are files with the same name in the various namespaces!!

On Thu, Jan 22, 2009 at 2:17 AM, Mauro Iazzi <mauro.iazzi@gmail.com> wrote:

2009/1/21 Anders Backman <andersb@cs.umu.se>:

> Ok a few more comments:
> Im starting to test to export a bunch of classes, and it works for quite a
> lot of the code, problems and ideas are listed with # below:
>
> #1 obj.__gc = obj.delete -- scope deletion
> Could this be beatified somehow?

do
local n = QObject.new
QObject.new_local = function(...)
local ret = n(...)
ret.__gc = ret.delete
return ret
end
end

> #2 I did not get delete to work at all:

It was a problem with the namespace patch. It should be fixed now.

> #3 Tried virtual methods

> #4 The virtual method is not exported to lua so:

> #5 nested classes as I indicated before does not work:

I'll look into those in the next days...

> #6 library naming convention
> Right now the naming convention of the dynamic library is perhaps not
> optimal.

correct. but as you noticed there are even bigger problems :)