Beginning with the TreeViewItem help example:
t = TreeView().front;
t.columns_(["one", "two", "three"]);
t.addItem(["Alice", "Anna", "Anders"]);
t.addItem(["Bob", "Beatrice", "Benny"]);
t.addItem(["Cleo", "Conrad", "Cecilia"]);
i = t.itemAt(1); //get an item
i.addChild(["Bengt", "Bodil", "Ben"]);
i has one child.
Is there a method that I could call on
i that would answer 1 for this case? (Or answer
2 if the item has two children?)
The lack of this information somewhat complicates tree traversal (though one can just
while until reaching nil). I was tempted to file this question under Development for that reason.
This is maybe a bit roundabout, but why not
.strings gives you the columns within one row – I’m looking for the number of rows.
Fortunately an out-of-range index in
childAt simply returns nil, not an error, so iteration is possible with
while. But… incrementing an index by hand in a while loop is dated – even C had to define an alternate syntax for that.
do or a variant for this case, but there’s not a nice clean way to use it here because you have access to neither the number of children nor an array of the children themselves. (You do have access to the number of top-level items, but not the item count at lower levels – which makes me think the class interface is simply incomplete.)
I guess, PR time. (Though that will introduce a version requirement for the quark where I’m using it.)
Oh, the class file definitely doesn’t show anything.
Stands to reason that this should be implemented on the main branch. Is this going under your ddw quarks?
As sometimes happens, upon reflection it becomes more complex than it initially seemed.
A flat iterator over items at one level is easy. A flat iterator over items and their descendants is also easy.
But a flat iterator wouldn’t handle all possible cases. In my specific case, I’m representing instruments and presets in a GUI: instrument names as top-level TreeItemViews, and preset names by adding children to the instrument items (so that the instrument names can fold and expand).
A flat iterator would pass in either an instrument or preset name, and it may not be obvious at the time which is which.
So I would really need a tree data structure that would provide information, at each node, about the position within the tree, and sync the GUI to this. SC has MultiLevelIdentityDictionary, but this isn’t adequate because data exist only at the leaves. So then the problem becomes one of implementing a general tree object suite (with design decisions to make). That’s probably upwards of half a day if I didn’t make design mistakes, and at least that much time for thorough documentation.
I’m not going to be able to do that quickly.
Maybe sometime… It’s a bigger job than I thought. Though tbh, I’m not that interested in this problem – would be good to have but I’m not sure it’s good to put other, music-related tasks aside for a couple days to do this.