Hi Sean.

����, 5 ������. 2020 ��. �� 16:15, Sean P. DeNigris <sean@clipperadams.com>:
I had a "simple" goal: to change Calypso's class pane to a tree. After an
hour or two, I didn't feel any closer!

I implemented it in very early stages. But I did have time to implement it in a better way.��
The old code is still there. But I did not expose it to the browser widgets API.��
Try to replace following line in ClyFullBrowser>>switchToFlatClasses
classView showQueries: classQueries as: ClyExtensionLastSortedClasses hierarchical
with:��
fullQuery := ClyQuery unionFrom: classQueries as: ClyExtensionLastSortedClasses hierarchical.
classView initiateUIChangeBy: [
�� �� dataSource := ClyExpandedDataSource on: fullQuery.
�� �� classView dataSource: dataSource.
�� �� classView ensureSelectedItemIfNeeded].

The trick is to use��ClyExpandedDataSource��instead of ClyCollapsedDataSource. The former is responsible to provide expansion to predefined internal tree structure (which you see in default browser).
I wanted to merge them but I had no time for that.����

I thought to myself,
packages are already in a tree, let me dig there! I got a bit worried when I
saw what seemed to be a mini-DSL for tree making instead of simple message
sends:
�� �� ClyFullBrowser >> #newPackageView
�� �� �� �� ...
�� �� �� �� �� �� �� �� treeStructure:�� {
�� �� �� �� �� �� �� �� �� �� �� �� ClyProjectChildItem -> #prepareProjectItemsQueryFrom:in:.
�� �� �� �� �� �� �� �� �� �� �� �� RPackage -> #prepareClassGroupQueryFrom:in: };
But I pressed on and tried to duplicate that logic:
ClyFullBrowser >> #newClassView
�� �� �� �� ...
�� �� �� �� ^ self newNavigationView
�� �� �� �� �� �� �� �� treeStructure:�� {
�� �� �� �� �� �� �� �� �� �� �� �� Class -> #prepareProjectItemsQueryFrom:in: }

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.
��
Denis

�� �� �� �� �� �� �� �� �� �� �� �� ...

And... nothing. When #prepareClassItemsQueryFrom:in: didn't exist, I got no
debugger. When I created it, placing a halt in it never got triggered.

Besides my immediate experiment of making the class pane a tree, my more
fundamental questions are:
1. What is the best heuristic to explore the system? This would be great to
put somewhere publicly. Especially, but as we can see from this post not
exclusively, for new users.
2. Do we value discoverability?
3. If so, are we designing our system with this value in mind?



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html