[Pharo-dev] how to set another inspector/explorer

Marcus Denker marcus.denker at inria.fr
Sat Nov 2 02:17:37 EDT 2013

On 01 Nov 2013, at 22:49, Tudor Girba <tudor at tudorgirba.com> wrote:

> Hi,
> I am trying to set the GTInspector as the default explorer.
> However, I see that the inspector registration has changed. It seems to me that registering to #objectExplorer has no effect. Instead, we are now sending #inspect: and #explore to the #inspector:
> Object>>explore
> 	^Smalltalk tools inspector explore: self
> I do not quite see the rationale behind the current design.

With the new inspector, the inspector and explorer are the same tool. If you open a normal inspector, you can even turn it into an explorer with a keyboard shortcut. 
Therefore it makes conceptually no sense to have a #objectExplorer tool. There was a basicInspector in the tools, too, which is now gone. 

Explorers are just special inspectors, like the special inspectors for CompiledMethod or Dictionary, just available for all classes.

> Furthermore, Smalltalk tools still has an entry for #objectExplorer:
> (Smalltalk tools instVarNamed: #tools) at: #objectExplorer ==> ObjectExplorer
It should not. I thought I removed it. ObjectExplorer should be removed eventually (it is now only used for the PointerExplorer, which is a subclass).

> Anyway, I added #inspect: and #explore: to GTInspector class, and I registered it as the #inspector. It seems fine, but the problem now is that the default Spec-based debugger relies on a #inspectorSpec method in the inspector class.
> This is highly problematic and I am stuck. I think we should not introduce Spec-specific requirements at such a basic level.

It should normally not “leak” that the inspector is implemented with Spec, you should be able to replace the inspector (via Smalltalk tools) with another one.
So this should be checked and fixed.

But it is clear that we can not have all the tools “in a crap version in the kernel” and “that version that everyone uses”. This Philosophy is *wrong* just the same
for tools as it is for libraries.


More information about the Pharo-dev mailing list