Denis Kudriashov wrote
Try to replace... with...
Thanks!! That added tree node arrows to the class tree :) but the icons and arrows themselves are not properly indented (they are all in one vertical line regardless of depth in tree) :/ BTW am I alone in thinking that the class list should be treated as a tree by default? It basically is a tree *already*, but without the ability to collapse/expand which limits understanding a large tree where siblings may be far apart when it's fully expanded. Also, I can't imagine ever coming up with all that on my own, so I'm glad I asked, but I'm worried about the future extensibility/maintenance if original authors aren't available :/ Denis Kudriashov wrote
You were in the right direction. But there is a little detail here. By default your code would work for domain objects in the list (not a class view). But the problem with classes and methods lists is to support the Ring model where classes are not instances of Class and methods are not instances of CompiledMethod. My solution was to have a data type for query items. By default it is an actual class of objects. But for classes and methods I introduced ClyClass and ClyMethod to address the Ring case.
So try following in your experiment ClyClass -> #prepareProjectItemsQueryFrom:in: And you should have a debugger.
I wonder, did you try a halt in #treeStructure users . I think it would help to discover this logic.
I checked for senders of #treeStructure (there were none) and then references to the underlying inst var, but for some reason my eyes glossed over `queryToExpand:ifAbsent:` and I only ran across it much later in a debugger, but I don't remember from what route. Although, given your solution above, is this even necessary? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html