Chapter 5: Our Smalltalk Application

We’re going to write an application to query the hardware for vital information and display this information on the screen in a nice visual format. This requires special code, written in C language, to access the hardware. I have taken the liberty of providing this code for you. Normally, you’d have to find C code that performs this functionality (code which is poorly documented), analyze the code in detail to understand how it works, and repackage the code for your own use. This is arduous, and it requires you to understand C language. But this is one of the common tasks a programmer must learn how to do.

See Addendum: C Library at the end of the tutorial for more information about this hardware access C code.

Smalltalk provides a mechanism for calling C functions. It’s called the Unified Foreign Function Interface (or uFFI). This is a very useful way to enhance Smalltalk’s capabilities.

A simple example illustrates its use. Let’s say you want to call the C function:

clock_t clock(void);

For simplicity, we’ll consider ‘clock_t’ as a ‘uint’ data type. (Don’t worry about all of this C jargon. Just follow along.) The clock function resides in a shared library called ‘libc.so.6’. From Smalltalk, you would send the ffiCall:module: message to yourself (since the method is inherited from the universal Object class):

self ffiCall: #( uint clock() ) module: 'libc.so.6'

This says call the function represented by the symbolic string ‘uint clock()’ which can be found in the module or library ‘libc.so.6’. Easy peasy.

There are a few other details you may want to take care of, but for now this is enough for you.

The Requirements

Our application has three basic requirements:

1. It must query the hardware for vital information such as kernel version, uptime, memory and swap usage, SD card usage, CPU temperature, etc.
2. It must display this information on the screen in a visually clear and readable format.
3. It must update this information in real time periodically.

The graphical layout of the screen for this application is programmed by using Morphic, a User Interface (UI) construction kit. A Morph is a graphical object. Everything in a UI is a Morph. A Morph can contain other Morphs. With this principle, you can build a UI of arbitrary complexity, and you can build it easily and flexibly.

Here’s an excellent series of videos that I found immensely useful in understanding Morphic:

(For a higher level GUI framework, see The Spec UI Framework.)

Morphs are living, breathing objects. You touch them, they respond. You can directly manipulate a Morph at any time, change its properties. You can bring up a context menu by meta-clicking on the object (press Ctrl-Shift while clicking). The menu will give you all the options available for this Morph.

As I said, a Morph can contain other Morphs. This is a good example of object composition. We discussed this in Chapter 3. Composition can be more useful than inheritance, and nowhere is this more obvious than in Morphic.