Creating custom browsers out of GTInspector extensions

The GTInspector empowers objects to display themselves through dedicated presentations. These are then wired together through the pager interface of the inspector. This provides a powerful way to experience and manipulate objects, but this is not the end of the story. Together with these dedicated presentations another opportunity opens up.

While the inspector is nice, it might still not always be desirable to use all the presentations. Let’s consider browsing the file system. Of course, we can use the default inspector, but if we are only interested in browsing files the relevant tabs are the one showing the items in a directory and the one showing the contents of a file. We can simply reuse the existing presentations and wire them up in a custom pager browser:

GLMPager new with: [ :pager |
     pager show: [ :composite :file |
          composite title: file basename.
          file gtInspectorItemsIn: composite.
          file gtInspectorContentsIn: composite ] ];
     openOn: FileSystem disk workingDirectory

The script simply delegates to the gtInspectorItemsIn: and gtInspectorContentsIn: methods already defined in the FileReference class. The result is a browser that looks like this:


Quite simple. Now, let’s imagine a more complicated scenario in which you want to work on a Pillar book. As announced recently, the inspector offers dedicated presentations for Pillar.

Once you know that you will spend quite some time working with Pillar projects, you might prefer a dedicated browser that only exposes the presentations that you care about. We can extend the above browser to take these presentations into account.

GLMPager new with: [ :pager |
     pager show: [ :composite :file |
          composite title: file basename.
          file gtInspectorItemsIn: composite.
          file gtInspectorPillarConfigurationIn: composite.
          file gtInspectorPillarIn: composite.
          file gtInspectorPillarProjectIn: composite.
          file gtInspectorPngIn: composite.
          file gtInspectorGifIn: composite.
          file gtInspectorContentsIn: composite ] ];
     openOn: FileSystem disk workingDirectory

Once we were at it, we added also the PNG preview for good measure. What we get is a browser that looks like this.



Essentially, with the above, we have created a scoped GTInspector. However, we are not constrained to wire the presentations in a Pager. We can actually use any other Glamour browser we want. Let’s try another variation in which the file tree is shown to the left and the preview is shown to the right.

GLMTabulator new 
     with: [ :t |
          t title: 'File Browser'.
          t column: #directories; column: #preview.
          t transmit to: #directories; andShow: [ :a :root |
               a tree
                    title: root fullName;
                    display: { root };
                    format: #basename;
                    children: [:each | each isFile ifTrue: [{} ] ifFalse: [each children]]].
          t transmit from: #directories; to: #preview; andShow: [ :a :file |
               file gtInspectorPillarConfigurationIn: a.
               file gtInspectorPillarIn: a.
               file gtInspectorPillarProjectIn: a.
               file gtInspectorPngIn: a.
               file gtInspectorItemsIn: a.
               file gtInspectorContentsIn: a ].
          t transmit from: #preview port: #strongSelection; to: #directories port: #selection ];
     openOn: FileSystem disk workingDirectory

The script produces a browser that looks like in the pictures below. Most of the script is straightforward. In the first column we show the file system tree, and in the second column we show the contents of what is selected. Perhaps less obvious is the line at the very end that connects the strong selection port of the preview with the selection port of the directories. This is a little bonus to make it possible to double click on items displayed to the right and have them selected in the tree.




The GTInspector implements the philosophy of a moldable development environment in which tools should be customizable easily and extensively. On the one hand, the GTInspector makes it easy to create and expose multiple presentations for an object. On the other hand, these presentations are not captive in the inspector, but can be used in other contexts as well with little effort.

With the right infrastructure, investing in various custom presentations has more benefits than meets the eye at first sight. The interesting thing is that we can now easily imagine creating rather sophisticated tools with little code and that we only use for a very short time (e.g., minutes). This has a rather high disruption potential given that no other environment I know of allows for something like this.

Posted by Tudor Girba at 14 October 2014, 11:19 pm with tags tooling, moose, pharo, analysis link

Writing Pillar books with the GTInspector

Documentation is regarded as an important activity in the Pharo community. Besides commenting code, a significant documentation effort is being invested around books. For example, one of the ongoing such project is the Pharo for the Enterprise.

The book is written in Pillar, a wiki-like syntax extracted by Damien Cassou from the Pier content management system. The Pillar project offers transformers into several target formats such as LaTeX, html or markdown.

It’s quite a nice package. The only problem is that it offers no tool support for editing book contents, and as a consequence, people prefer using external editors that offer a minimal source highlighting. That is a no go for an environment that touts itself as being live.

I teamed up with Andrei and Jan to change this.

We needed several things to get this to work. First, we needed a text widget that can handle custom syntax highlighting. To this end, Andrei extended the Rubric text editor (authored by Alain Plantec) and its integration in Glamour to make it more suitable for the task.

Second, we needed the logic of producing the syntax highlighting. For this purpose we needed a parser. Pillar does come with its own hand-written parser, but the parser was only conceived for generating other formats and it does not come with any support for mapping parsed constructs to the original source. This is where the work on island parsing of Jan comes in. With an island parser we can match subsets of the input without needing to understand the whole input. This is particularly valuable when building a syntax highlighter. It’s a bit like regular expressions, only more powerful.

The end result looks like this:


We get as you type highlighting for headers, links, embedded files, notes, code etc directly in the GTInspector for each file that has a pier or pillar extension. Adding new constructs is as easy as extending the parser. For example, the embedding rule is specified as:

     ^ '+' asParser , file token , '+' asParser ==> [:res |
          GTPillarFileHighlightingCommand new
               token: res second]

Granted, the parser is not fast. In fact it is more than an order of magnitude slower than the hand-made parser that comes with Pillar. It would ideal for the Pillar parser to keep track of tokens as well, but until then, the island parser is cheap and it works reasonably given that the highlighting happens in the background.

Perhaps this does not look like much, but this is the first time when we can have a cheap way to manage custom highlighter in Pharo. Yet, the highlighting was actually not the end goal of this exercise. Let’s put it in perspective for a second. Highlighting is a necessary step to bring the effort of writing Pillar-based documentation inside Pharo, but once this is achieved, the interesting things happen when we start to take advantage of the live environment.

For example, the syntax highlighting of Pharo code is done by simply delegating to the code highlighter (i.e., Shout). This is easily possible exactly because we are inside Pharo.

Other opportunities open up as well. For example, a Pillar book is made of multiple files (one per chapter) placed in subfolders of the root book folder. These must then be linked from a pillar.conf file that is placed in the root folder. Given that the logic is entirely in Pharo, when we inspect the root directory of a Pillar book, the inspector can offer us a Pillar specific index. For example, the picture below shows the folder of The Moose Book that I started to rewrite using Pillar. Selecting a file from the index previews the highlighted content to the right.


Essentially, we get a cheap book editor. And when we are ready with editing, we can simply trigger the generation of the output directory from the inspector (see the play button on the top right).

One trouble when handling such books written in a language that is not visual is to manage the links to external pictures. To show the potential of a tight integration, the current solution comes with a simple tool support that provides a link for every embedded file (in our example, we have pictures/glamour-presentations-details.png). If the file cannot be found on the harddisk, the text becomes red. If the file is found on the harddisk, the text becomes a magenta link. Clicking on the link spawns the file object to the right offering a quick preview possibility.


To get this behavior, load the following code in a Moose 5.0 image, and inspect the directory of a Pillar book.

Gofer new
     smalltalkhubUser: 'Pier' project: 'Pillar';
Gofer new
     smalltalkhubUser: 'JanKurs' project: 'PetitParser';
     configurationOf: #PetitParserIslands;
#ConfigurationOfPetitParserIslands asClass loadDevelopment.
Gofer new
     smalltalkhubUser: 'Moose' project: 'GToolkit';
     package: 'GT-InspectorExtensions-Pillar';

The current solution is an exercise that opens up new possibilities. An easy application is that of enhancing the rendering of class comments. For example, when loading the aforementioned packages, you also get the ability of rendering class comments with Pillar syntax.


But, we can envisage bolder directions as well. One clear direction is to go towards more live book writing. For example, if we stay in the image, we can also manage all code snippets in real methods instead of having them copied as text in a book. Pillar could simply provide a way to embed a method like +method:Object>>#printString+ and this would embed the method code while still allowing the writer to preview the code. Yet another thing is to move towards eliminating static pictures. For example, most pictures in a technical book are some sort of screenshots. These screenshots could easily be produced with snippets that could be generated. Thus, the book would only include a way to embed the result of a piece of code like +object:aScriptThatGeneratesAGraphicalForm+.

Yet another direction is to bring the books inside the image and link them to the code they talk about. Imagine that every packages comes with a dedicated chapter that offers scenarios of usages, and each scenario links explicitly to methods. In this case, when browsing the methods in question, you can get relevant scenarios to read about.

I am certain there are many other ideas that will flourish by bringing liveliness to documentation. We just have to be bold. I invite you to join us.

Posted by Tudor Girba at 7 September 2014, 3:27 pm with tags tools, moose, pharo, analysis link

GTinspector received the 1st prize at the ESUG Innovation Awards

The GTInspector, part of the Glamorous Toolkit authored by Andrei, Alex Syrel and myself, received the 1st prize at the ESUG 2014 Innovation Awards.

These awards work like this: on the first day we get a 2-3 hours slot to demo in the open hall, and at the end of it the participants vote. It was great fun to demo the inspector. I alone gave some dozens of demos both on that day and afterwards. I can now do it with my eyes closed.

The work was met with quite some enthusiasm. Already during the conference several people extended the inspector for their own contexts, and we even had a couple of presenters showing their work through inspector extensions created during the week of the conference.

This is highly encouraging, especially keeping in mind that we just got started.

And yes, the trailer did help spreading the word:

Posted by Tudor Girba at 24 August 2014, 11:27 pm with tags moose, pharo, tools, analysis link

Moose: how to solve real problems without reading code (video from ESUG 2014)

I gave the above talk at ESUG 2014. The abstract went as follows.

Moose is a platform for software and data analysis ( It runs on Pharo and it can help you figure out problems around software systems.

In this talk, I show several real-life examples of how custom tools built on top of Moose helped solve concrete problems. The examples vary both in scope and in the kind of problems. For example, we talk about how we fixed a caching problem in a Java system by analyzing logs, or how we fixed a Morphic problem by means of visualization and interaction. Even if these problems are so different, all of them were solvable with one uniform set of programmable tools.

That is the power of Moose, and it is now at the fingertips of any Pharo programmer.

Posted by Tudor Girba at 23 August 2014, 9:24 pm with tags moose, pharo, tools, analysis link
| & GTInspector trailer

As part of the submission for the ESUG 2014 Innovation Awards, we launched a webpage dedicated to the Glamorous Toolkit for Pharo at

And, to make it more exciting, we put together a trailer to exhibit the power of the inspector and the playground.

Posted by Tudor Girba at 15 August 2014, 1:34 pm with tags moose, pharo, tooling, assessment link
<< 1 2 3 4 5 6 7 8 9 10 >>