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:
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.
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:
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.
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.