Club Amiga de Montreal - CAM/CAM_CD_1.iso/files/083.lha/twm/TWM.article

Text File | 1986-11-20 | 9KB | 157 lines

TWM - A Paneless Approach to Tiny Window Management

by Nick Sullivan

(   This text is a slightly adapted version of an article from Volume 8,
 Issue 4 of Transactor Magazine.
    Freely distributable, but copyright (c)1987, Transactor Publishing Inc.)


Most programs on the Amiga can be divided into three fairly tidy classes.
The commonest class consists of programs like DIR and LIST, that you invoke
as commands, that do their work then exit. Another class consists of
handlers, like the console handler ConMan, or PopToFront, from a few
Transactors ago. These programs, or their offspring, live in the system
usually until next reboot, but because they require no user interaction, they
are invisible.

Programs in the third class are the ones you interact with for an extended
period of time, such as text editors, terminal emulators and paint programs,
or that you might keep around for sporadic interaction, such as PopColours
and Structure Browser. One benefit of the Amiga's multitasking environment is
that you don't have to take such programs down in order to do something else.
You can switch readily from your editor to your terminal, for instance, and
keep your text in memory; you can switch from the terminal back to the editor
and stay on-line.

The extent to which you can take advantage of this capability depends, of
course, on how much RAM you have in your system in relation to the size of
the programs you're running. Even with a lot of expansion RAM, though, you
are still limited by the amount of available "chip RAM" - the special area
of memory that the Amiga's custom chips can use. On current Amigas, chip
RAM is limited to 512K and, while that sounds like a lot, it can quickly
get eaten up by programs that use lots of windows, colourful screens,
gadgets, and other display elements that need chip RAM to survive.

The other problem with running a lot of interactive programs simultaneously
is that they tend to crowd your monitor screen. That makes for a lot of
depth-arranging and resizing as you flit from one task to another - the
infamous "electronic shell-game" - and can get pretty tiresome if you have
to do a lot of it. A few programs even put up a full-size window and won't
allow you to get at the Workbench screen behind.

One approach that some programs have taken to relieve the on-screen
congestion has been to supply a "tiny window mode", which can be invoked when
the program is not in active use. This idea was arrived at independently
quite a while ago in at least two programs I know of - Rick Stiles' shareware
text editor Uedit, and Chris Zamara's PopColours. In Uedit particularly, use
of the tiny window (invoked by clicking on the editor's title bar) achieves a
significant savings in chip RAM. Using a normal 640 by 200 window on the
Workbench screen, which has two bit-planes, Uedit needs 32K for its bit-map,
plus a bit more for gadgets. Its tiny window, however, is a mere 100 by 20
pixels in size, and so consumes less than 600 bytes. Clearly, the chip RAM
penalty for running concurrent applications would be considerably eased if
the use of a tiny window mode was more widespread.

A tiny window consists of no more than an inch or two of title bar with an
equivalent thickness of empty window beneath. It is draggable, and may be
depth arranged (since part of its purpose is to keep the application that
owns it out of your hair), but not resizable. Clicking in the empty part
reactivates the parent program, prompting it to take the tiny window down,
put its working window (or screen) back up, and carry on with business as
usual.

One reason for this article is to advocate the use of tiny windows in
programs - including commercial programs - in which their use is appropriate
(for one approach to implementing a tiny window mode see the listings for
"TWM" and "Test1"). Suppose this idea *were* generally adopted,
though, making it easier to run several such programs concurrently. Now the
user has another problem: the new disorder of TWL (Tiny Window Litter), in
which one's visible workspace is obscured by annoying swarms of tiny windows
that continually seem to be getting in your way as you work, no matter how
much you try to shuffle things around.

So the other reason for this article is to present TWM, for 'Tiny Window
Manager', a small and easily implemented piece of code that enables programs
to support a tiny window mode while giving users a method of avoiding the
anguish of TWL, and the consequent disruption of their lives.

From the user's point of view, TWM is a kind of central storage compartment
in which sleeping programs are housed, and from which they can be activated.
The programs do not have to maintain any display of their own - not even a
tiny window - so the user's screen is free from clutter. TWM's own working
window contains gadgets bearing the names of its "client programs". When the
user clicks on one of these gadgets, the corresponding client program is
awoken and resumes operation. TWM also has its own tiny window mode; when
that is in use, the amount of chip RAM jointly consumed for graphics by the
client programs and TWM itself is very small. When the system is hosting two
or more applications that support TWM, there is a significant savings in both
resources and convenience. Of course, even if TWM is not running,
applications that support it will run normally - but instead of disappearing
entirely when they go to sleep, they will put up a tiny window in the usual
way.

From the programmer's point of view, TWM comes in two parts - the program TWM
itself, and a short C-language module called twmClient.c. The twmClient code
can be compiled and linked with any application that supports a tiny window
mode. Let us suppose that this client application has been running in its
active mode but now, as a result of some action of the user's (perhaps a menu
selection, perhaps clicking on a gadget) it has taken down its working
display and is about to put up its tiny window and go to sleep.

Before taking that step, the application now calls the function PostMe() in
the twmClient module, passing as an argument the name by which it would like
to be known, as in:

   PostMe("PopColours");

PostMe(), in its turn, searches the system for a public message port with
the name "TinyWindowManager". If the search succeeds, PostMe() sends a
message to that port with the name of the client, and waits at its own
message port for a reply. Effectively, the client application has now let
itself go to sleep and, because it has closed its working window, there are
no visible signs of its existence.

The message sent by the client is now picked up by the TWM program, which the
user has earlier run, and which is now displaying one of its own windows
(either the tiny window or the larger working window) on the user's
screen. On receipt of the message TWM creates a gadget bearing the client
application's name. The gadget will be displayed in TWM's working window
(immediately, if that window is up). There may be other gadgets in the window
also - one for each client application. This is the only indication that the
clients still exist and, when TWM is in its tiny window mode, there is no
sign of them at all. Chip RAM is conserved, and the user's window is
uncluttered. When the user later clicks on the gadget, TWM replies to the
message the client sent, deletes the gadget, then forgets about the client
altogether.

Back now to PostMe(), waiting asleep at its message port for a reply to its
message. The reply has finally come, signifying that the user has selected
the client's gadget in the TWM working window, and wants the client to put
up its own working window again. PostMe() now returns to the client, with
the value TRUE, and the client goes back to work.

Several things might have gone wrong along the way. The most probable of
these is that the user may not currently have TWM running. A remoter
possibility is that TWM might have failed to allocate memory for the client's
gadget, or could not open a window. In all these cases, PostMe() returns
FALSE to the client, who then knows that it is necessary to put up a tiny
window of its own after all.

As you will see in the code, there are other details. In case the client
application wishes to wake itself up (in response to time-out or some other
kind of message) while it is in TWM's care, an UnPostMe() function is also
provided. Most clients won't need UnPostMe(); in that case, the programmer
can remove UnPostMe() from twmClient.c to shrink the code even further.
Another detail is that TWM remembers where the user last placed its windows,
and restores them to the chosen position each time they are re-opened. Uedit
and PopColours also have this feature, and it is recommended that other tiny
window programs include it.

The intent of TWM is to institute a standard of which all tiny window
programs can take advantage. Therefore all the code is freely
redistributable, and may be used in any program - PD, shareware, or
commercial.