Work to make StMessageBrowser integrated in Calypso.

[Ducasse]

We get the old message browser in

Pharo 14.0.0 Build information: Pharo-14.0.0+SNAPSHOT.build.326.sha.cff1fd04e669d5fdb783a3ea09e21e1b5a95c9af (64 Bit) 30 November 2025

Now this is good since the API are different.

The rest of this issue is a record of a coding session with the StMessageBrowser as registered in the tools registry.

I get a DNU here because of the different API.

spawnBrowser: aBrowserClass withState: navigationBlock
	| browser |
	browser := aBrowserClass on: navigationEnvironment systemScope: self systemScope.
	browser disablePluginsWhichAreNotIn: self.
	browser prepareInitialStateBy: navigationBlock.
	self openAnotherBrowser: browser.
	browser wasSpawnedFrom: self.
	^browser

[Ducasse]

To make it work for implementors and senders (we are missing references to).

I did the following changes

"protocol: #'*Calypso-SystemTools-QueryBrowser'"

ClyBrowserMorph >> browseSendersOf: aSymbol


	StMessageBrowser browseSendersOf: aSymbol.
	"self spawnQueryBrowserOn: (ClyMessageSendersQuery of: aSymbol)"

[Ducasse]

"protocol: #'*Calypso-SystemTools-QueryBrowser'"

ClyTextEditor >> implementorsOf: selectedSelector

StMessageBrowser browseImplementorsOf: selectedSelector.

"self browser
	browseImplementorsOf: selectedSelector
	inNameResolver: self browserTool selectedClassOrMetaClass"

[Ducasse]

There is also

ClyTextEditor >> sendersOf: selectedSelector

	self browser
		browseReferencesTo: selectedSelector
		inNameResolver: self browserTool selectedClassOrMetaClass

[Ducasse]

When we press the little arrow showing methods of the superclass we get also a problem.

ClyShowLocalImplementorCommand >> execute

	| selectors query |
	selectors := methods collect: [ :each | each selector].

	query := ClyMessageImplementorsQuery ofAny: selectors from: self createQueryScope.
	
	browser spawnQueryBrowserOn: query withState: [:queryBrowser |
		self selectMethodsIn: queryBrowser ]

[Ducasse]

I hacked a first version as. It is bad since it does not take into account multiple methods and in addition it does not work for the down arrows. But a step at a time.

"protocol: #execution"

ClyShowLocalImplementorCommand >> execute

	| selectors query |
	selectors := methods collect: [ :each | each selector].

	StMessageBrowser browse: 
			{(browser classView selection actualObjects first lookupSelector: methods first selector)}
	
	 asImplementorsOf: methods first selector 
		
	"
	query := 	ClyMessageImplementorsQuery ofAny: selectors from: self createQueryScope.
	browser spawnQueryBrowserOn: query withState: [:queryBrowser |
		self selectMethodsIn: queryBrowser ]"

[Ducasse]

To be able to work while StMessageBrowser does not support (or maybe this is hidden) class References. I did the following.

ClyShowClassRefCommand >> execute

	"browser spawnQueryBrowserOn: (ClyClassReferencesQuery toAny: classes)"
	
	SystemNavigation default browseAllUsersOfClassOrTrait: classes first
```	 

[jecisc]

To me we should have a lit of traits defining the APIs of what we can register in the list of tools. Like TInspectorAPI, TMessageListAPI, etc with methods to define in the real classes. Else, it's kind of useless to have a registration mechanism of tools if each have different API

[Ducasse]

I changed my mind. see below

[Ducasse]

Now I defined also (obviously I'm breaking the scoping) but this is just to be able to continue to work.

browseUppercasedReferencesTo: aSymbol inNameRespolver: anEnvironment


	"browser spawnQueryBrowserOn: (ClyClassReferencesQuery toAny: classes)"
	
	SystemNavigation default browseAllUsersOfClassOrTrait: (Smalltalk globals at: aSymbol ifAbsent: [^ self]).
	
	"
	anEnvironment 
		ifNil: [
			^ {
				  (self spawnQueryBrowserOn: (ClyClassReferencesQuery of: (self class environment at: aSymbol))) .
				  #SendersWithouEnvironment 
				} ].

	(anEnvironment bindingOf: aSymbol) 
		ifNotNil: [ : envBinding |
			^ (envBinding value isClass and: [envBinding value isPool])
				ifTrue: [ 
					{ 
						(self spawnQueryBrowserOn: (ClySharedPoolReferencesQuery of: envBinding)) .
						#SendersWithEnvironment 
					} ]
				ifFalse: [ 
					{
					  (self spawnQueryBrowserOn: (ClyClassReferencesQuery of: envBinding)).
					  #SendersWithEnvironment 
					} ] ]."

[Ducasse]

The tool registry is good because it let us do the experience I'm doing. Now the tools should have the same API within the same tool and this is normal.

Another point StMessageBrowser should be able to browse class references.

[jecisc]

To me the registry is not so bad because it allows other to customize their environment. This got used in Moose to register a moose playground or a moose inspector.

What is bad is that we have nothing to define the API. It's the reason I think it might be nice to have a trait for each tool to define the API. A class to subclass would be too limited because tools needs to subclass some different presenters