[Kde-bindings] Qt bindings for Lua

[Sebastian Sauer]

Sorry for the late reply, I was a bit filled with work last few days ;)

Mauro Iazzi wrote:

> On 13/09/2007, Sebastian Sauer <mail at dipe.org> wrote:
>> Mauro Iazzi wrote:
>>
>> > I strongly hope that this is of some interest to someone.
>>
>> Looks damn cool. I just ask myself why an own parser is used and not
>> smoke which got already used for ruby, C#, php, ... ? anyway, keep up the
>> great work and I'll press all of my fingers, that we have working
>> LUA-bindings soon! :)
>>
> 
> I tried to have it the smoke way, but I did not understand well how to
> use it. So for a bunch of motives I resolved to make it by myself. One
> of those motives is that I don't assume it is the best way of doing
> this, just a simple one.

What sounds imho like the best reason since the most easy way may result in an 
easy implementation what may pay out on maintaining :)

> I also have a binding of the Qt's moc which does exactly the same of
> QtScript for Lua. I could not give it the same interface of QtScript
> (as suggested by a recent post in tha planet by Aaron Seigo) because
> Lua and Javascript are not similar at all and I could not translate
> the concepts of Javascript into Lua's. The subject (JS <-> Lua
> translation) has undergone great discussion in the Lua mailing list,
> but no definitive solution has been found. If anyone wants to see the
> code, I will post. I may try to resurrect it if someone feels it is a
> good idea.

I would like to see it (even if I am not that deep into LUA yet) cause your 
realization sounds very promissing).

> I have recently solved a lot of memory faults, I feel the code is
> complete. I think I have to put it into a repository, so If noone is
> contrary, I'll tell the list when it will be up somewhere.

Maybe to check out http://techbase.kde.org/Contribute/Get_a_SVN_Account may an 
idea. Afaik things that are not ready yet need to be developed in 
trunk/playground/bindings. That has afaik the reason, that it's that way not 
a big problem to break things, you don't need to take care of compatibility, 
have time to improve the solution and let it envelop sometime, be able to 
offer at some time a fully working solution without big "but that's not 
working yet" markers, drive the initial codebase to a working solution, etc.
 
> Finally, I just consider this as a proof of concept, basically. Given
> that it could use gcc directly (just writing a lot of C code, to
> interface directly) this means that bindings could be done at compiler
> level. I stress I have no clue about what _should_ be done, but this
> is a test...

np. I did by myself spend quit some time to test things, refactor them, etc. 
till I found the way that works best (for me) and even then it can be made 
better. Guess that's the fate of software but also one of the most 
interesting things on it. Well, probably also valid for other things then 
software.
 
> I'm glad that someone likes it, thank you

how can I not like to see someone working on the same topic then myself 
(that's to connect the KDE-world with the scripting-world). Re my initial 
smoke-question; and that was only for personal interest. Whatever you thing 
may the best way to solve that rather complex problem will be the right way 
and as user I care about the solution only anyway and not how it was 
reached ;) Those that codes decides or something like that.