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:
I gave the above talk at ESUG 2014. The abstract went as follows.
Moose is a platform for software and data analysis (http://moosetechnology.org). 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.
As part of the submission for the ESUG 2014 Innovation Awards, we launched a webpage dedicated to the Glamorous Toolkit for Pharo at gt.moosetechnology.org.
And, to make it more exciting, we put together a trailer to exhibit the power of the inspector and the playground.
The talk I gave at NDC on "Pharo: Playing with Live Objects" is now publicly available.
On the one hand, the talk shows how programming with Pharo can be both serious and fun at the same time. On the other hand, the talk exhibits the liveliness of Pharo through demos of the GTInspector.
Recently, we rethought the Print It action in Pharo. On that occasion, we replaced the text inlining with a popper that leaves the initial text editor untouched.
Another behavior that lends itself to a popper treatment is the notification of compilation errors.
Suppose that we have a case like this:
In a classic Smalltalk-like interface, if we try to compile the code, we get this:
The contents of the text editor get modified with the error message. Like in the case of default Print It behavior, the text does get selected to enable the developer to quickly dismiss the text by pressing Backspace. However, like I showed in the case of Print It, this approach presents shortcomings:
- the original editor gets dirty,
- the highlighting gets messed up, and
- it is easy to lose the selection by clicking with the mouse somewhere else.
But, in the case of the error notification, we have a couple of add-on problems. First, while for Print It, there are indeed cases where you need the text for further comparisons, in the case of the error, you never want that text, so it should certainly not appear in the text editor. Second, the error appears exactly in the same way as the printout, which is not at all proper as errors should always be distinct.
So, Andrei and I propose a different kind of implementation.
You get an error popper that addresses all of the above problems, while still preserving the ability to quickly dismiss it via Backspace or Esc.
The implementation is available in the latest Moose and can be experienced in the Playground and Inspector.
Just one interesting note. The -> string that comes at the end of the error message is not a glitch of the popper implementation. It is actually part of the message sent by the compiler to the requestor (typically the text editor) like this:
self compilationContext requestor
notify: exception errorMessage , ' ->'
at: exception location
in: exception errorCode.
Essentially, the error message was fine tuned for the user interface. This was hard to spot when the interface was textual, but it became apparent when the interface changed. The benefits of reification apply to user interfaces as well.