Introducing the GTPlayground

One of the concepts that Pharo inherited from its Smalltalk ancestors is the Workspace.

The workspace is a little utility that lives next to the Inspector and it serves at least two large use cases:

  1. It lets you execute code snippets. This is particularly convenient for various things, such as loading code from a repository using Gofer scripts, or initializing objects from the image.
  2. It lets you initiate an investigation by inspecting the result of executing a piece of code.

The workspace is designed as a simple standalone code editor. For the first usage, it’s enough of a concept as the only thing you need is a place to write code. But, let us focus on the second case.

Suppose you want to investigate a file reference from the working directory. You start by typing:

FileSystem disk workingDirectory

You inspect the result, and continue in the inspector. This results in two unrelated windows that you have to manage. We have followed this workflow for 30 years. It’s time to rethink it.

Default-workspace.png

Let’s imagine a different situation in which you have an inspector already opened on FileSystem disk, and you execute self workingDirectory. Indeed, with the default inspector you end up with two unrelated windows, but with the GTInspector you get only one workflow.

Looking at these scenarios, it should follow that we should be able to integrate the workspace with the inspector. Enter (GT)Playground.

The GTPlayground (part of the GToolkit) is essentially a GTInspector in which the first pane is just one editor that has no binding for self. That’s it. Everything else works exactly as in an inspector.

Thus, if you press Cmd+o, you spawn the object to the right, like in the regular inspector. So, our example looks like:

Playground.png

This can look like a minor difference, but it can have some surprising consequences. First, you get a simple mechanism for previewing intermediary code while playing with it. Take a look at the video below:

But, more interestingly, it can play the role of a generic editor for all sorts of use cases. For example, Moose provides a dedicated editor, called easel, for developing Roassal visualizations. The new GTPlayground can offer a similar behavior without the need of a specialized editor. It simply takes advantage of the inspector being able to show a preview of the view object (and of course, the feature of remembering the last viewed presentation). This can be applied equally well to any kind of engines that offer a preview.

Playground-easel.png

The playground also remembers all snippets you are playing with (you can get a similar functionality in the default workspace). As soon as you close a playground, the code is stored and you can retrieve it from the dropdown menu from the top right. Thus, you can play without worrying for losing content.

The playground is a new take to an old problem. There are still things to improve (for example, create variables dynamically) but the difference is already significant.

Ah, before I forget: the current implementation has 68 lines of code.

Posted by Tudor Girba at 23 February 2014, 9:22 pm with tags moose, pharo, tooling, assessment link
|