[Pharo-dev] how to set another inspector/explorer
tudor at tudorgirba.com
Sat Nov 2 04:44:04 EDT 2013
On Sat, Nov 2, 2013 at 7:17 AM, Marcus Denker <marcus.denker at inria.fr>wrote:
> 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.
I agree that the explorer is like the inspector. But, if now they are the
same, I do not see why we need to distinguish between them. I would leave
only #inspect (no more #explore) around.
However, a stripped down basic inspector can still be useful as a fallback
solution in case the fancy one fails given that it relies on much more
widgets that can cause exceptions. For example, try this in a fresh Pharo
Smalltalk tools explore
You will get an exception. Having a basic inspector around is useful in
As it is now, the basic inspector is wrapped in a more complex widget which
can induce errors in the future, and we get stuck. So, all in all, I argue
that we need a basic inspector mapped on a more complicated keyboard
> Furthermore, Smalltalk tools still has an entry for #objectExplorer:
> > (Smalltalk tools instVarNamed: #tools) at: #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
Yes, I know. I was just pointing this out to show that I looked and that I
was not sure of the current state.
> > 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.
+100. I completely agree that the core needs powerful tools. That is why I
actually argued for Glamour in that base image a long time ago. I still
want to make that argument, but this is a discussion for another time :).
"Every thing has its own flow"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev