Path: utzoo!attcan!uunet!samsung!brutus.cs.uiuc.edu!apple!netcom!cooper
From: cooper@netcom.UUCP (Ken Cooper)
Newsgroups: comp.lang.smalltalk
Subject: Smalltalk Interface Builder
Keywords: interface builder smalltalk
Message-ID: <4692@netcom.UUCP>
Date: 29 Nov 89 06:59:47 GMT
Organization: NetCom- The Bay Area's Public Access Unix System {408 997-9175 guest}
Lines: 80

I've received several requests for information about the interface builder
we're working on, so I thought I'd post a little information to satisfy
curiosity.  Some portions of the design are not yet finalized, so we invite
comments and requests.

The interface builder is a part of a set of tools we're working on to help in
programming GUI 'applications' in Smalltalk V/286 and Smalltalk V/Mac.  We may
end up porting this to Smalltalk V as well, but we have yet to see what the
issues are there.

The basis of the interface builder is a set of reusable classes, or widgets,
which implement the functionality of standard GUI mechanisms.  Each widget
manages its interaction with the user, and sends relevant messages to its
registered owner only when something interesting occurs.  For example, a
button widget would handle all button presses, giving the user feedback that
the button was pressed, sending a message to its owner only when the mouse was
released within the button.  If you're used to MVC, this model brings the View
and Controller into one package, avoiding much of the spaghetti so typical of
Panes and Dispatchers.

Each of these widgets is a class, and we've designed them to be subclassable
for different looks and feels.  With this, one can easily change an
application's appearance to look like the Mac, MS Windows, Next, or a look and
feel of one's own design.

We're implementing all the common user interface components, including
windows, dialog boxes, list boxes, popup and pulldown menus, scrollbars,
buttons, checkboxes, radio buttons, and text edit boxes.  In addition, we're
providing less common components, like hierarchical menus, icon palettes, and
numeric editors.

[The emacs-like window I described before was the text edit box.  This is
*not* an emacs goody;  it won't implement a lisp interpreter, and thus you
won't be able to port code from emacs to it.  I describe it as emacs-like
because smalltalk code can be bound to keys, and because the standard motion
keys can match those of emacs. (Since all widgets have programmer definable
event bindings, binding keystrokes to commands in an editor rides along for
free). It's written with smalltalk in mind, so commands like "select current
line and show it", or "extend selection to end of paragraph" will be
available.]

The interface builder itself allows one to 'paint' applications made up of
these components.  If you're familiar with NextStep or Prototyper, this is
very similar: one creates an interface by dragging its component widgets off a
palette, editing each of them individually, and then saving the unit as an
instance.  Unlike these systems, the interface and code can be changed and
executed interactively;  one can watch one's objects in action as the
interface is built.

To deal with handling all the resulting instances, we've created a mechanism
for saving and retrieving instances by name or keywords, with a facility for
saving unused instances to disk to avoid bulging images. This will have a
front end "finder" similar to the Macintosh's SFGetFile dialog box, with
keywords as the mechanism for limiting a search rather than directories.

Further, we've defined a class called a module, which is a collection of those
classes and instances that make up a unit of functionality (e.g. a "program",
or a library of classes).  A module  can use this same mechanism for storage
and retrieval to minimize image size, and further, a module can be exported
into a disk file that another programmer with these tools can then import.
This provides a mechanism for exchanging code far superior to fileIn and
fileOut, since GUI applications often require instances such as fonts,
bitmaps, and icons in order to run (and we all know how much support there is
for instance transfer).   We also provide a simple mechanism for isolating
platform specific code (e.g. directory pathnames on V/286 don't look like
those on V/Mac), so one can write a module that is *truly* portable across
platforms.

All of these tools have GUI and programmatic interfaces.  The graphical
interfaces for these tools are consistent with each other, and fit together
into a consistent programming environment.  

That's about it.  Any comments?

Ken

=============================================================================
Ken Cooper                                         USENET: cooper@netcom.uucp
Acumen Software                                Compu$erve: 71571,407
=============================================================================