Issues added

[Ralf Van Bogaert]

Hi,

I opened an issue on Github for every bug in lqt I could think of.

I'll add new ones if encountered - and properly verified first.

I seem to be unable to change the label for an issue - otherwise I would have added them to 'Missing'.

Regards

Ralf

[Michael Kirsch]

I also have a lot of issues with lqt that seem like they should be
fixed. Should I put them on GitHub, too?

On Apr 30, 3:19 pm, Ralf Van Bogaert <ralf.vanboga...@gmail.com>
wrote:

[Ralf Van Bogaert]

You might want to post them here first to see if they are genuine bugs in lqt.

[Michael Kirsch]

On Apr 30, 4:34 pm, Ralf Van Bogaert <ralf.vanboga...@gmail.com>
wrote:

> You might want to post them here first to see if they are genuine bugs in
> lqt.

They're mostly API inconsistencies and important (IMO) missing
features (not exactly bugs), but here they are:

* Errors print the line where the error happened and the program keeps
running (instead of printing a backtrace and exiting).

* Errors in an event handler print an error that says thay exceptions
can't be thrown is event handlers in Qt, and it prints no debugging
information al all.

* Objects should not be deleted by the GC if they have a parent. That
way, I can actually not worry about memory (as it should be in a
scripting language). (Does this actually not solve the problem
completely, since QObject pointers might be stored in objects that are
not parents?)

* Enums are very inconsistent about where you can pass strings or
numbers, and some enum names are not implemented so you have to enter
raw value right into your code. For example, QDialog.Accepted is not
implemented, so I have to write "mydialog:exec() == 1" instead. Also,
QMessageBox.question() returns a string, not a number. Why does
QDialog.exec() return the enum's number, while QMessageBox.question()
returns a string?

* It should be possible to store any Lua value (including tables) in a
QVariant (which can be very useful for storing things in an item's
UserRole).

* It should be possible to connect a signal to an ordinary Lua
function, like this: "myobj:connect('2exampleslot()', function ()
print 'slot called' end)". It would also be nice to add a variation of
the function that specifies an argument to prepend to the slot's
arguments before calling the function, like this:
"myobj:connect('2exampleslot()', myreceiverobj,
myreceiverobj.mymethod)". I guess this should be possible since other
Qt scripting language bindings (including QtLua and PyQt) do it.

* It's very difficult to work with QStringLists. You have to create
the object and add the items one by one. It would be great if you can
pass a Lua table wherever a QStringList is expected, or at least give
QStringList a constructor that takes a table.

* I wonder if it's possible to have a nice, easy way to properly
subclass Qt classes in Lua, instead of creating an object and manually
adding your functions to every instance. If not maybe something like
this is an acceptable solution:

function lqt_subclass(methodtable, base)
setmetatable(methodtable, {
__call = function (...)
local instance = base()
table.copy(instance, methodtable) -- a function that
copies items from one table to another
if methodtable.constructor then
methodtable.constructor(instance, ...)
return instance
end,
})
return methodtable
end

MyWindow = {}

function MyWindow:constructor(text)
self:examplemethod(text)
end

function MyWindow:examplemethod(text)
self:setCentralWidget(QLabel(text))
end

lqt_subclass(MyWindow, QMainWindow)

[Ralf Van Bogaert]

* Objects should not be deleted by the GC if they have a parent. That
way, I can actually not worry about memory (as it should be in a
scripting language). (Does this actually not solve the problem
completely, since QObject pointers might be stored in objects that are
not parents?)

I'm having problems with this too. For example, declaring the parent in the constructor of a locally declared widget does not prevent Lua from deleting the object when garbage collecting. This can be circumvented by setting a global pointer, but still.