Rethinking compilation notifications in Pharo

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:

Problematic-script.png

In a classic Smalltalk-like interface, if we try to compile the code, we get this:

Error-classic.png

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.

Error-popper.png

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.

Posted by Tudor Girba at 3 August 2014, 9:57 pm with tags analysis, tooling, moose, pharo link
|