[rust-qt-binding-generator] [Bug 395192] rust-qt-binding-generator: unable to compile multi-dimensional list
https://bugs.kde.org/show_bug.cgi?id=395192 Jos van den Oever changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[rust-qt-binding-generator] [Bug 395192] rust-qt-binding-generator: unable to compile multi-dimensional list
https://bugs.kde.org/show_bug.cgi?id=395192 Justin Zobel changed: What|Removed |Added CC||justin.zo...@gmail.com Severity|crash |normal -- You are receiving this mail because: You are watching all bug changes.
[rust-qt-binding-generator] [Bug 395192] rust-qt-binding-generator: unable to compile multi-dimensional list
https://bugs.kde.org/show_bug.cgi?id=395192 --- Comment #5 from carl --- Thank you for explanation. It's really helpful. -- You are receiving this mail because: You are watching all bug changes.
[rust-qt-binding-generator] [Bug 395192] rust-qt-binding-generator: unable to compile multi-dimensional list
https://bugs.kde.org/show_bug.cgi?id=395192
--- Comment #4 from Jos van den Oever ---
The functionality that you want is possible, but quite some work.
The Model/View in Qt is based on QAbstractItemModel. The current code creates
one QAbstractItemModel for a List or a Tree. Each node in the List or Tree has
the same properties.
Your binding is for a List with a top level of nodes that have `name` and
`novel_list`. Each `novel_list` of type `Source` has a list of items again:
`chapter_list`. So your model is a tree but the nodes on each level have a
different type. It is a clear and logical model from a data modelling point of
view.
A logical Rust structure for this would be
struct Sources {
name: String,
novel_list: Vec,
}
struct Source {
name: title: String,
chapter_list: Vec,
}
struct Novel {
index: u32,
title: String,
content: String,
}
In Qt Model/View each node in a tree has an index and all nodes are basically
the same. The delegates that render the nodes also treat all nodes the same.
But each property can have a different role. If you want to show this model in
a QTreeView or TreeView, you'd specify a different role or column for each
property. So the role numbers and column numbers should be unique for the
properties in the combination of Sources, Source and Novel. The solution I gave
you does that. But it does not look as nice as the structure you want.
The current code could be expanded to interpret Sources, Source and Novel as
belonging to one Tree. It would be very nice, but hard to implement such an
addition to the code generator.
The solution I gave is also flawed in that I forgot to add `optional`:
"objects": {
"Novels": {
"type": "Tree",
"itemProperties": {
"sourcesName": {
"type": "QString",
"optional": true
},
"sourceTitle": {
"type": "QString",
"optional": true
},
"novelIndex": {
"type": "quint32",
"optional": true
},
"novelTitle": {
"type": "QString",
"optional": true
},
"novelContent": {
"type": "QString",
"optional": true
}
}
}
}
This limitation in the generator is also present in Qt itself. If you write C++
code with QAbstractItemModel, you'd face the same issue that it expects each
node in the tree to be the same.
--
You are receiving this mail because:
You are watching all bug changes.
[rust-qt-binding-generator] [Bug 395192] rust-qt-binding-generator: unable to compile multi-dimensional list
https://bugs.kde.org/show_bug.cgi?id=395192 --- Comment #3 from carl --- Sorry for not giving any sign of live. I read your O.2 announcement and remembered that I posted this bug report a long time ago. I read you answers and I found your solution a bit 'hacky'. Is where at some point something in rust, cpp or qt that could forbid to use multidimensional list. I already saw that the new version don't need #[derive(clone)] anymore and with for example the new `impl trait` syntax in rust. Can't we not implement multidimensional list in this binding generator? I not yet very experimented with the model-view architecture, so maybe I forget something important. I'm looking at your code right now, and I will try to implement something. -- You are receiving this mail because: You are watching all bug changes.
[rust-qt-binding-generator] [Bug 395192] rust-qt-binding-generator: unable to compile multi-dimensional list
https://bugs.kde.org/show_bug.cgi?id=395192
--- Comment #2 from Jos van den Oever ---
I recommend writing the binding like this:
"objects": {
"Novels": {
"type": "Tree",
"itemProperties": {
"sourcesName": {
"type": "QString"
},
"sourceTitle": {
"type": "QString"
},
"novelIndex": {
"type": "quint32"
},
"novelTitle": {
"type": "QString"
},
"novelContent": {
"type": "QString"
}
}
}
}
Then you model it such that a novel has QAbstractItemModel::parent() which is
the source and the source has a parent() which is the list of all sources.
--
You are receiving this mail because:
You are watching all bug changes.
[rust-qt-binding-generator] [Bug 395192] rust-qt-binding-generator: unable to compile multi-dimensional list
https://bugs.kde.org/show_bug.cgi?id=395192 --- Comment #1 from Jos van den Oever --- The binding.json that you use has nested lists. That is currently not supported. The bug is that there is no error message for that. You can nest a List or a Tree in an Object. Could you remodel the structure into something where there is no nesting of Lists of Trees? -- You are receiving this mail because: You are watching all bug changes.
