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
