Closed jlgerber closed 4 years ago
The issue is caused by the fact that these slots are declared using QModelIndexList
which is a typedef for QList<QModelIndex>
. ritual
resolves and discards all typedefs, so it doesn't have information about QModelIndexList
, but Qt for some reason doesn't want to recognize QList<QModelIndex>
as a valid alias for QModelIndexList
(although it's able to recognize some other type alises).
I've made a hacky fix of this issue (it simply replaces QList<QModelIndex>
with QModelIndexList
in all receiver IDs). I'll also need to create a way to test for successful connection so I can at least write a test for this hack. I hope there are no slots that use QList<QModelIndex>
as their argument because that would make the issue much harder to fix.
I'll post here once the fix is published.
Thanks a bunch. This will make it possible to recognize drag and drop reordering.
Fixed in qt_widgets 0.5.0-alpha.1
.
I have a QListWidget that I am looking to connect a signal from (the signal appears in the docs as coming from QListView via Deref). I implement a SlotOfQListOfQModelIndex and attempt to connect them like so:
This compiles fine, but when launching the application, I get this error:
That definitely looks like the right C++ signature to me....
Update
I tried implementing this using the qlistview and the QStandardItemModel. I ran into the same issue.
My slot is defined like so:
is it an issue with my slot? I suspect there is a signature mismatch between the signal which is a const pointer and the slot, which is a const reference...
NB I also tried this with a RawSlotOfQListOFQModelIndex ....
Or...
The signal is not defined correctly in the library. in QT, the signature of the method is :
but in rust-qt it is:
shouldnt that be