[prev] [up] [next]

Classes to know are:


Much of the drawing protocol is defined in abstract classes. These can be subclassed to support drawing on canvases other than bitmaps and views.

For example, a public domain goodie adds support to draw on a Postscript printer page. Therefore, the same piece of code that did the view redraw can now be used to send a hardcopy to the printer.

Most of the graphics functionality is implemented in the GraphicsContext and DeviceDrawable classes - these keep a handle to the actual underlying drawing device (i.e. a bitmap, a view or a postscript printers page), and forward low level drawing requests to that device.

Press here for more details about: GraphicsContext or: DeviceDrawable.


The View class provides the most of the GUI functionality - although in a very generic and abstract way. It deals with resizing, redrawing, startup and closedown of views.
Most other GUI components inherit (i.e. are subclassed) from this class.

All user interface components in Smalltalk/X are implemented as (direct or indirect) subclasses of View. Therefore, starting with View, you will find all components (such as Buttons, ScrollBars, TextViews etc.) in the subclass hierarchy.
The most heavily used protocol:

Press here for more details about: the View classes protocol.


Instances of this class represent topViews on your display screen. TopViews are the outer frames, which typically have a window title, can be iconified, and are managed by the displays window manager.

This class provides protocol to define a views icon, window title and position on the screen. On systems which support this (i.e. X displays with Shape extension) arbitrary shaped views (like round clocks) are supported.
Also iconification, icon windows, size constrains and manual focus change via the keyboard are supported.

The most useful protocol:

After creation (possibly with many subviews), the view must be made visible.
This is done by sending it the #open message - and called opening the view.

Views can be opened modeless (the new view is handled by an independent process and control returns immediately to the sender of the open message) or modal (the new view is handled by the calling process; control returns when the new view is closed).
By default, all dialog views open up modal, all other views open modeless. However, you can send all an explicit openModeless or #openModal message to get around that default behavior.

Notice, you cannot depend on the view being really open right after sending it the #open message - the reason is that the open operation starts a new process for the view. By default, the new process executes at the same priority as the currently running process - therefore, the actual opening will be done later, when the current process is suspended (typically, when it waits for input).

If you want to draw into the new view (from the creating process) right after the open message, you have to make certain that the new view is really open.

Press here for more details about: StandardSystemView or: TopView or: DialogBox. Typical uses:

More detailed information and a step by step tutorial is found in ``Introduction to view programming''.

Copyright 1995 Claus Gittinger Development & Consulting


Doc $Revision: 1.20 $ $Date: 2016/01/21 16:22:39 $