Doug McKenna is president of Mathemæsthetics, Inc. and author of Resorcerer®, the premiere and Eddy-award-winning Macintosh resource editor. Among his childhood hacks were a variety of ingeniously designed and less-than-benign mousetraps, as well as a private hand-built telephone line to a friends house. The line was eventually destroyed by lightning (fortunately the houses grounding either end werent). His first computer amusement was a canonical ASR-33 teletype paper-tape jingle bell hack. Although (or perhaps because) his parents let him play with matches at age six, fireworks at nine, and dynamite at twelve, his pyromaniacal tendencies have long since evolved into more constructive endeavors in the explosive virtual world of editing interfaces.

The Lessons Of Two Old Hacks

Back in the early 70s, when I was more of an innocent lad than I am now, I had a summer job in the MIS department of a large industrial tool company where I got to hack out BASIC programs on a teletype-based system. One day, I came across a program called Screwball (author unknown), which provided me with the first and probably the most important lesson Ive ever learned about user-interfaces.

Screwball was a typical practical joke hack. Some would say it had no social-redeeming value, or that it was a proto-virus. But I can still feel the utter amazement I had when I finally realized what it did. Or rather, what its author had done to my head. Upon running Screwball, I (the user) was presented with some silly question, the actual wording of which I no longer remember. Regardless of the answer typed back, the teletype responded with some equally silly or insulting (screwbally) answer, and then the program ostensibly exited back to BASICs command line shell. Except that it didnt: if I recall correctly, Screwball used the then-relatively-new CHAIN command to secretly (or rather, silently) transfer control to another program whose entire user-interface was the same as BASICs interpreter, only things didnt work quite right! The programs in the workspace directory wouldnt run; strange error messages would arise under what used to be normal conditions; etc. When you tried to LIST SCREWBALL.BAS (or whatever), Screwball would list itself with a modification that excluded the final CHAIN instruction, so regaining your bearings in the face of this rogue programs control over your perceptions was not a trivial task.

Ive forgotten whether I figured out how Screwball worked, or whether Screwball itself was eventually forgiving enough to let me understand (that is, to truly exit after some not-too-secret incantation), but when I did figure it out I had a real epiphany: a computer program could be about more than just computing, it could be about controlling another persons perceptions, which, for ill or for good, is the heart of what a user-interface is all about.

As an April Fools joke a few years later, I created my own version of Screwball, only this time it was for the entire DEC PDP-10 operating systems command-line-interface and commonly-run system utilities, which included a variety of user-interfaces, including a full-screen source code text editor, all of which had to be cobbled together enough to fool and annoy an accomplished user for, say, a minimum of 5-10 minutes. Having nothing better to do, it took me two weeks of hacking 18/hours a day to create it in Fortran and assembly. What I learned from the hack was that it is always a lot easier creating an inconsistent interface than it is designing a consistent one. And also that the sleep researchers were right about the natural human sleep/wake cycles being longer than 24 hours in the absence of natural cues, of which most computer rooms of the time were devoid.

The lesson of both these hacks is that a user-interface can immerse the user in a metaphor at a different level than the underlying computation, and if the metaphor is appropriate and self-consistent then all is well and productive for the user. If not, the user will inevitably become frustrated, or will waste time thinking about the computer rather than the task at hand (or maybe will be the butt of a practical joke!). Screwball and its ilk were intentionally designed to be frustrating; our modern graphical user-interfaces are, with only partial success, designed not to be.

Which brings me to why I wrote my FEZ hack for the MacHack/MacHax conference/contest. Its my little contribution to a more consistent graphical user interface on the Mac, and it partially solves a visual problem that has bothered me for a couple of years now. With machines being so much more powerful these days than ten years ago, doing the extra computation isnt a problem. And it really looks way cool!

Standard ZoomRects

In the Mac Finder and other graphical desktop user-interfaces, icons represent documents, applications, folders, or other types of system objects. Internally, these are usually files that can be opened or closed, although the act of opening or closing the various classes of icons can mean different things. Usually, opening an icon means that another window gets created on the desktop. It is the Finders main purpose in life to support the graphical metaphor that the underlying hierarchical file system is a series of nested folders whose windows show the contents of the folders they represent.

When you double-click on a folder icon in a Finder window, the new window appears at its last position. From a visual logic point of view, this is fairly unambiguous, because you know which icon you just clicked on (and you dont really care about it once the window is opened), and you know where the window that just opened is. However, in the opposite situation when you close a folder window on the desktop, it is not always easy to see which folder icon among the many icons in the underlying window is the representative icon for the window being closed. Thus was born the idea of zooming rectangles, which is a simple technique to provide animated visual feedback showing the link between a window and its icon elsewhere on the desktop.

The current zooming rectangles algorithm, usually known among Mac programmers as the ZoomRect routine (you have to roll your own; its not in the toolbox), takes as input the bounds of an icon, the bounds of a window frame, and the direction of the zoom. Because the animation in general takes place between windows on the desktop, all coordinates must be in global desktop coordinates and all drawing has to be in the global Window Manager port. This in turn means that all drawing must be non-destructive: if you muck with a pixel on the desktop, it is your responsibility to restore it to its old value as soon as possible, because pixels on the desktop (that is, in the Window Manager port) are shared among applications (processes). In the current cooperative multitasking environment, you can take control of the desktop pixels as long as you restore them prior to allowing the system control again. Drawing something twice in exclusive-OR mode is the easiest and fastest method of doing this. [NOTE: In the future, with pre-emptive multitasking, drawing to the desktop will of necessity be even more constrained since any one process may not have any knowledge of when other processes are also writing to the desktop.]

Figure 1: Standard zoom from a visible icon

The standard ZoomRect routine creates a series of rectangles, with each one being part of a simple linear interpolation in global screen coordinates between the two boundary rectangles. Most ZoomRect implementations interpolate between corresponding corners of the starting and ending rectangles; however, for my hack, I began by re-implementing the standard routine to perform the entirely equivalent interpolation between the centers of the two boundary rectangles, and to linearly interpolate between the two sizes. I also chose to avoid the Fixed point routines so I could keep my code simple:

ZoomCenterRect

This new routine does the same thing as a linear ZoomRect(), except that instead of interpolating between the four corners of the two limiting Rects, we interpolate along a line between the two limiting Rects centers, and between their two sizes. This sets us up to provide a more general routine that follows any path, instead of the implicit straight line that ZoomRect() would travel. This code doesn't care about the direction of the zoom, which is now implicit in the order of the two rectangular arguments; nor whether either of the Rects is empty. Both input Rect pointers must be non-NIL and in global coordinates. The thickness parameter should normally be 1 pixel, but was added during MacHack to enhance the demo by giving more visual weight to the zooming rectangles.

/* 1 */
void ZoomCenterRect(Rect *startRect, Rect *endRect, short thickness)
{
Point startCenter,endCenter,startSize,endSize;
Rect r1,r2,r3,r4; short zoomSteps,x,y,w,h; long i;
if (!InstallDesktop()) // Draw outside of all windows
return;// or do nothing at all if problem
// Get centers of the two limiting rectangles
startCenter.h = (startRect->left + startRect->right) / 2;
startCenter.v = (startRect->top + startRect->bottom) / 2;
endCenter.h = (endRect->left + endRect->right) / 2;
endCenter.v = (endRect->top + endRect->bottom) / 2;
// And the starting and ending half sizes
startSize.h = (startRect->right - startRect->left) / 2;
startSize.v = (startRect->bottom - startRect->top) / 2;
endSize.h = (endRect->right - endRect->left) / 2;
endSize.v = (endRect->bottom - endRect->top) / 2;
/* Fill the rectangle queue with empty rectangles so nothing gets drawn
initially as the queue fills up. The queue makes for a better zoom effect,
since there will be more graphic weight to the zooming, and the amount
of time any particular rectangle is displayed is will be longer. */
SetRect(&r1,0,0,0,0);
r2 = r1;
r3 = r1;
PenSize(thickness,thickness);// For demo only, usually its (1,1)
zoomSteps = 16; // Can be set to any number here
for (i=0; i<=zoomSteps; i++) { // loops zoomSteps+1 times
// The following arithmetic is susceptable to overflow for short
// coordinates with large magnitudes (e.g. shorts greater than
// (32K/zoomSteps), so we do our intermediate calculations in longs
// by making i a long. If zoomSteps is a power of 2, it is also a
// lot faster to replace the divide-by-zoomSteps with a right-shift
// by that power of 2. Or you can go back and use the Fixed point
// that some of the older ZoomRect implementations use.
// Find the i'th intermediate position along line between centers
x = ((zoomSteps-i)*startCenter.h + i*endCenter.h)
/ zoomSteps;
y = ((zoomSteps-i)*startCenter.v + i*endCenter.v)
/ zoomSteps;
// And i'th intermediate sizes (also interpolated linearly)
w = ((zoomSteps-i)*startSize.h + i*endSize.h)
/ zoomSteps;
h = ((zoomSteps-i)*startSize.v + i*endSize.v)
/ zoomSteps;
// Build the next interpolated rectangle out from its center
SetRect(&r4,x-w,y-h,x+w,y+h);
// Draw the newest zooming rectangle into the queue
FrameRect(&r4);
// Erase (assuming xor mode) the i-3'rd previously drawn rectangle
FrameRect(&r1);
// Shift rectangle queue up by 1, leaving r4 ready to be redefined
r1 = r2; r2 = r3; r3 = r4;
// Use governor so processor speed doesn't affect zoom
Wait(1);
}
// Erase last three zoomrects to empty the queue of drawn zoomrects
// and to clean up any final desktop drawing
FrameRect(&r1);
FrameRect(&r2);
FrameRect(&r3);
ResetDesktop(); // Restore normal drawing environment
}

The ZoomCenterRect routine in turn relies on some utility routines that will be useful in the coming FEZ enhancements. These routines manage the changing drawing environment:

Convert a rectangle in place from local coordinates to global ones with respect to the given port. If port is NIL, this will be the current port. This code is Mac specific in that it knows that a Rect structure is two Point structs next to each other.

Create a new port the size of the current desktop, and initialize its drawing environment for drawing and erasing xored zoomrects. Each successful call to InstallDesktop() must be matched by a call to RestoreDesktop() and unlike the above, they cannot be nested. This routine should deliver TRUE if all goes well, FALSE if memory or other problem.

One problem with doing a brute force linear interpolation between two global rectangles on the desktop is that the icons position may be partially or wholly outside the bounds of the window in which it is drawn. This usually doesnt occur when you open an icon by double-clicking on it since, by definition, double-clicking on an icon means that it had to be at least partly visible. However, in the Finder it is possible to select an icon, decrease the size of the window it is in so that the icon is no longer visible, and then open the still-selected icon using a keyboard command. It is also possible for the Finder to open a selected but hidden icon via an AppleEvent.

Closing the hidden icons opened window poses the same problem, and a bad zoom is also easily seen when you Option-open a folder, which action closes the previous window after opening the folder on top of the window being closed. And the problem occurs in other contexts, such as in Resorcerers Dialog Editor, where dialog items can be placed both inside and outside the dialog windows frame, and the editor supports opening any item into its own information window. Actually, its a bit worse in Resorcerer, because the editor also supports formally hiding dialog items (a la HideDItem), which means moving them 16K pixels (or about 19 feet) to the right, guaranteed to be off of even the most absurdly large desktop when converted to global coordinates. Interpolating (in 16 or fewer increments) a series of rectangles from so far away guarantees that nearly all of them will be uselessly offscreen.

In these not-uncommon cases, the standard ZoomRect algorithm gets called by code that converts the bounds of icon (or item or widget) into global coordinates that are outside the bounds of its window, and ZoomRect zooms blindly to or from what is, as far as the user is concerned, essentially some random spot in a background window or the desktop. This provides erroneous visual feedback for the first part of the zoom (when opening) or the last part (when closing) and thus misinforms the user for no good reason.

So the hacker in me thought (to paraphrase one of the alltime great hackers, Conrad Cornelius ODonald ODell), Most people stop at Z[oomRect], but not me!

Frame Evading ZoomRects (or FEZ)

From now on, I (and the source code) will refer to widgets instead of icons, since the problem applies to icons, dialog items, list items, or any other openable-from-within-a-window-into-its-own-window object. To solve the problem of zooming between a widget hidden within a window and a visible window on the desktop, I generalized the path between the centers of the boundary rectangles to be a curve instead of a line. Furthermore, the zoom has to be divided into two parts so that the curve passes through some point in the visible interior of the window whose frame hides the widgets position. When travelling between this center point and the hidden widget, all zooming rectangles should be clipped to the interior of the window; for the other half of the zoom, clipping can be to the whole desktop (or as well see later, some portion of it). The result is a much more visually pleasing and dynamic-looking zoom that enhances the careful 3D layered illusion of windows on the desktop. The zoom looks like it actually comes right out of the window at you, thereby living up to its name!

Figure 3: Opening a hidden widget with frame clipping

Even with this generalization, though, there are still going to be visual problems that ruin the metaphor of the graphically inviolable window. For instance, these days when opening a widget into a new window, it is no longer the case that the new window will be frontmost: there can be any number of floating palette windows in front of it that need to be zoomed under, not over. This can occur even if your own application has no floating palettes, because the system can put up things like balloons or text input windows for Kanji, etc. So we can no longer discard window information about either end of the zoom, which the standard ZoomRect does by expecting everything in preconverted global coordinates.

To be truly general as well as visually correct, though, you have to take into account the entire window list ordering, and analyze it completely before the zoom. This is because it is quite possible (in fact it frequently happens in the Finder) for there to be intervening windows between a window being closed and the window that holds the widget towards which the zooming rectangles are travelling. To create the illusion that windows are graphically inviolable and layered in a 3D way, you have to force the zoom to treat them in an ordered 3D manner so it can evade them, not travel right through them. With an infinitely visible desktop, a zoom could simply travel out to the side of the union of all windows, change direction, and sneak back into the window list looking for the final destination window. However, on a small desktop, the curved path of the zoom can be arbitrarily complex as it tries to find the best path to its destination while remaining on the visible screen(s).

Note that we are now in hacking-for-fun territory, not in designing-the-best-user-interface territory. There is a tradeoff between pure visual logic and not annoying the user with arbitrarily long animations not part of their immediate work needs. But not late at night at MacHack!

Bezier Splines

One of the easiest ways to create a general curved path without worrying about orientation or boundary conditions is to use a parameterized Bezier spline, which is a segment of a cubic polynomial that conforms to certain boundary conditions. Bezier curves are the basis of PostScripts curveto operator, and a routine to compute a series of points along the path of a Bezier can prove useful in lots of other contexts. The one Ive used for years is as follows:

Compute the path of a Bezier spline whose starting and ending knot points are p0 and p3, and whose control (tension) points are c1 and c2. The path should be stored in the array "path", which is expected to be able to hold (numPoints+1) elements, from 0 to numPoints, inclusive. numPoints should be a power of 2 between 2 and 32, inclusive. This routine can be easily generalized to 3D coordinates, and is optimized for fast computation in (long) integers. Since there are no divides, the routine does the right thing regardless of whether p0, c1, c2, or p3 are all different or coincident or whatever. For a derivation of this algorithm, see any textbook on graphics and Bezier splines. This routine assumes that a long is at least 32 bits, and that the magnitude of the size of the bounding box of the curve is not too large. On a PowerPC, youd probably want to do this in straight floating point, without all the integer (fixed point) scaling.

In order to create an arbitrarily complex curved path, you can tie a series of Bezier curves together, called a spline. This is why the segment endpoints are often called knots. As long as the closest control points on either side of a knot are colinear with the knot, then the pair of curve segments joined at the knot will be smoothly connected there (that is, the tangent at the knot will exist, and thus anything travelling along the curve wont suddenly change direction at the knot).

Precomputing the ZoomFrame Array

The first thing I did was create a record called a ZoomFrame, which holds for each end of a zoom segment all the information needed to do the right thing for a single Bezier curve. To do the entire frame-evading zoom, we will have to create an array of ZoomFrames: one for the window being opened or closed, one for the widget, and one for every window between. The array will hold all information needed to animate the zoom. In particular, each ZoomFrame has a precomputed clipping region that must be installed as the zoom passes through the frames knot. The array will always have at least two entries. The Fez.h header file for this looks like:

When opening a new window from a widget, the zoom must be performed prior to the window appearing, but the ZoomFrame array must be created after the window has been placed in its final position in the window list. When closing a window into a widget, the zoom must be performed after hiding the window being closed, but the array should be created before the window is hidden, since HideWindow changes the window list order.

Once the array of frames is created, you can perform the zoom by passing it to the routine FrameEvadingZoom. After the zoom, you must call DisposeZoom to return all the arrays storage back to the primordial memory soup whence it came.

Figure 4 shows all of the zoom rectangles created after closing the window Fez 1, which belongs to the icon in the background window Fez 0. The zoom travels underneath the two intermediate windows, Fez 2 and Fez 3.

/* 16 */
FEZ.c
Frame Evading ZoomRects
by Doug McKenna
(c) 1994 Mathemaesthetics, Inc.
This function precomputes an array of ZoomFrames for doing various types
of zooms on the desktop between theWidget and theWindow frames. The
delivered array will have at least 2 entries, with the first and last
entries the same as the arguments. When opening is non-zero (TRUE),
then the zoom travels from theWidget to theWindow; otherwise, the zoom
travels from theWindow to theWidget. The delivered array must be passed
to FrameEvadingZoom() to perform the actual zoom drawing later.
The caller must fill in the initial .win, .frame, and .thickness fields
of both ZoomFrame arguments before passing them into this routine. The
frame rectangle for theWidget should be in LOCAL coordinates with respect
to theWidget->win. The frame rectangle for theWindow should be in GLOBAL
screen coordinates. In either case, theWindow->win should be in its
final or current position in the Window List. If opening, you will want
to show the window after doing the zoom; if closing, you will want to
hide the window before doing the zoom.
The ZoomArray is allocated as a relocatable block on the heap and the
caller must dispose of it with DisposeZoom.
Delivers NIL if not enough memory or other problem.
ZoomFrameHandle NewZoom( ZoomFrame *theWidget,
ZoomFrame *theWindow, int opening)
{
RgnHandle clipRgn,tmpRgn; ZoomFrame *zf;
short numFrames,w,h,width,height,x,y,k,i;
WindowPeek wp; Rect ans,*bounds,*bbox;
ZoomFrameHandle zoomArray = NIL;
int okay = FALSE;
// Reality checks
if (theWidget==NIL || theWindow==NIL ||
theWidget->win==NIL || theWindow->win==NIL ||
theWidget->win==theWindow->win)
return(NIL);
// Install parameters in theWindow's private fields to pass to FEZ
theWindow->opening = opening;
// Start with entire visible desktop as clipping region for theWindow
clipRgn = NewRgn();
if (clipRgn == NIL) goto cleanup;
CopyRgn(LMGetGrayRgn(),clipRgn);
if (MemError()) goto cleanup;
// Subtract out all visible windows that are in front of theWindow.
// These are typically floating palettes (or text input windows or
// balloons).
// For each visible window from front, up to theWindows...
wp = (WindowPeek)LMGetWindowList();
while (wp!=(WindowPeek)theWindow->win && wp!=NIL) {
if (wp->visible) {
// Cut out its structure region
DiffRgn(clipRgn,wp->strucRgn,clipRgn);
if (MemError()) goto cleanup;
}
wp = wp->nextWindow;
}
if (wp == NIL) goto cleanup; // Reality check: should never happen
// clipRgn now contains all pixels on desktop except those that belong
// to windows in front of theWindow's.
// Get maximum number of windows for which we might have to
// create array entries
numFrames = opening ? 2 : 1; // theWindow is invisible when opening
wp = (WindowPeek)theWindow->win;
while (wp!=(WindowPeek)theWidget->win && wp!=NIL) {
if (wp->visible) numFrames++;
wp = wp->nextWindow;
}
if (wp == NIL) {
// Uh, ohh...theWidget->win is in front of theWindow->win (or
// not in the window list). This requires reversing various
// orders in things, so well punt for now, since this is a
// rare case (although its more likely to happen when closing
// than when opening). We deliver NIL to do nothing.
goto cleanup;
}
if (numFrames < 2) {
// when closing, theWidget->win was found, but was invisible
goto cleanup;
}
// Determine whether the widget is wholly visible in its window or not.
// theWidget's frame is expected to already be in local coordinates.
theWidget->isHidden = TRUE;
if (SectRect(&theWidget->win->portRect,&theWidget->frame,&ans))
if (EqualRect(&ans,&theWidget->frame))
theWidget->isHidden = FALSE;
// Create maximum array storage for entries, initialized to 0.
zoomArray = (ZoomFrameHandle) NewHandleClear(
numFrames * sizeof(ZoomFrame));
if (zoomArray == NIL) goto cleanup;
// Place theWindow at start of array, regardless of zoom direction
zf = *zoomArray;
*zf = *theWindow;
zf->clip = clipRgn; clipRgn = NIL;// Pass off clipRgn to first entry
// Traverse down the window list until we hit the widget's window
numFrames = 1;
wp = (WindowPeek)theWindow->win;
if (wp) wp = wp->nextWindow; // Skip first, we just did it above
while (wp != (WindowPeek)theWidget->win) {
if (wp->visible) {
// This is a good place to do any checks to cull windows that
// pose no threat to the zoom path. This is a pretty hard
// problem, but at the very least, we can ignore windows
// that do not cover the widget's window's content region,
// to which we will eventually be clipping.
bounds = &(*wp->strucRgn)->rgnBBox;
bbox = &(*((WindowPeek)theWidget->win)->contRgn)->rgnBBox;
if (SectRect(bbox,bounds,&ans)) {
// Need another knot in spline and intermediate ZF
// Initialize the next ZoomFrame's clipping
// region as whatever we've got before, minus
// its window's structure.
tmpRgn = NewRgn();// Use tmp before dereference
(*zoomArray)[numFrames].clip = tmpRgn;
if (tmpRgn) {
DiffRgn((*zoomArray)[numFrames-1].clip,
wp->strucRgn,tmpRgn);
if (MemError()) goto cleanup;
}
else
goto cleanup;
// Tell it which window it is evading, and keep same line width
zf = (*zoomArray) + numFrames;
zf->win = (WindowPtr)wp;
zf->thickness = theWindow->thickness;
// We will add information to the array after it has been
// created, since in theory you may need to do some kind of
// global search on the entire set of frames to find the best
// spline path. In the meantime, we record the window's
// structure region's bounds to be used in the next stage.
zf->frame = (*wp->strucRgn)->rgnBBox;
// Global coordinates
numFrames++;
}
}
wp = wp->nextWindow;
}
// Set the last zoom to the ending ZoomFrame for widget, and cut the
// array down to its final size, since we allocated a maximum number
// of entries above but may have culled some windows above.
(*zoomArray)[numFrames] = *theWidget;
tmpRgn = NewRgn();
(*zoomArray)[numFrames].clip = tmpRgn;
if (tmpRgn)
CopyRgn((*zoomArray)[numFrames-1].clip,tmpRgn);
else
goto cleanup;
// Cut the thing down to size
numFrames++;
SetHandleSize((Handle)zoomArray,numFrames*sizeof(ZoomFrame));
HLock((Handle)zoomArray);
// Convert theWidget's frame to global coordinates like all
// the other entries will be.
zf = (*zoomArray) + numFrames - 1;
LocalToGlobalRect(zf->win,&zf->frame);
// Got our zoom array, now all we have left to do is compute the
// frame positions next to the windows, and the knots and Bezier
// control points within them. In order to evade each window frame,
// the zoom has to find its way around the window, either above or
// below or to the right or to the left (or we could use octants
// for complete generality).
zf = *zoomArray;
for (i=0; i<numFrames; i++,zf++) {// For each ZoomFrame...
// For all the internal frames, change the frame position.
// The end frames are already in their final positions.
if (i>0 && i<(numFrames-1)) {
// Get width and height of window structure
width = w = (zf->frame.right - zf->frame.left);
height = h = (zf->frame.bottom - zf->frame.top);
// For maximum amusement, we set the midway zooms to be
// on various sides of the window frames, half size.
// Basically, rotate our zoom around each successive window
// This maximizes slinkyness and is very silly, but good for
// demo purposes. This is the spot in the routine where it
// would be appropriate to analyze the window pattern as a
// whole to try to optimize a simple path that evades the
// group as a whole to get to the destination frame. For
// a small number of windows, you could even do a complete
// backtrack search to find the shortest path, but I'll
// leave that for another day.
// Turn w and h into an offset to one side of window
k = i & 3; // Cycle every four frames
switch(k) {
case 0: w = 0; h = -(h+16); break;// 16 pixels above
case 1: w = (w+16); h = 0; break;// 16 pixels to right
case 2: w = 0; h = (h+16); break;// 16 pixels below
case 3: w = -(w+16); h = 0; break;// 16 pixels to left
}
OffsetRect(&zf->frame,w,h);// Move it outside window
// Make the thing smaller than entire window bounds
InsetRect(&zf->frame,width/4,height/4);
}
// Set knot to the center of its zoom rect frame for all frames
zf->knot.x = (zf->frame.left + zf->frame.right) / 2;
zf->knot.y = (zf->frame.top + zf->frame.bottom) / 2;
}
// Finally, traverse the array, using line segments between knots to
// choose spline control points that form a "smooth" path.
// If the two control points on either side of a Bezier spline knot
// are colinear, then the spline is continuous through the knot.
// This means the zoom won't too suddenly change direction as at passes
// each individual ZoomFrame entry in the zoomArray. The hard part
// is figuring out how to set the line that the two control points
// have to be on so that the path isn't too crazy. Note that if we
// have only 2 entries in the array, we don't have any intermediate
// knots to worry about.
//
// Naturally, this code would need to be sped up for older 68K macs,
// especially since the first time it's called it'll have to load
// the SANE package, but it seems to work reasonably fast on my
// PowerBook 180c (68030).
zf = *zoomArray;// It's still locked
zf->c0 = zf->knot;
for (zf++,k=1; k<(numFrames-1); k++,zf++) {
double theta,dot,cross,sn,cs; Point2D pt;
long dx0,dy0,dx1,dy1,len0,len1;
// Vector from last knot to this one
dx0 = zf->knot.x - (zf-1)->knot.x;
dy0 = zf->knot.y - (zf-1)->knot.y;
// Vector from this knot to next one
dx1 = (zf+1)->knot.x - zf->knot.x;
dy1 = (zf+1)->knot.y - zf->knot.y;
// Get the angle between the two vectors, (dx0,dy0) --> (dx1,dy1)
dot = dx0*dx1 + dy0+dy1;//Dot product = len0*len1 * cos(theta)
cross=dx0*dy1-dx1*dy0; //Cross product = len0*len1 * sin(theta)
theta = atan2(cross,dot);
// Get the sin and cosine of half the angle
theta = theta / 2.0;
sn = sin(theta);
cs = cos(theta);
// Rotate our initial vector by half the angle, and shrink
// it to a third its size (purely a heuristic: the larger
// this vector is, the more boisterous (wider) the Bezier
// turn will be. The result will be the vector between control
// points (through the knot) for this frame.
x = (cs*dx0 - sn*dy0) / 3.0;
y = sn*dx0 + cs*dy0 / 3.0;
// Set the two colinear control points for the next knot
(zf-1)->c1.x = zf->knot.x - x;
(zf-1)->c1.y = zf->knot.y - y;
zf->c0.x = zf->knot.x + x;
zf->c0.y = zf->knot.y + y;
}
zf->c1 = zf->knot;
HUnlock((Handle)zoomArray);
okay = TRUE; // Tell cleanup not to throw zoomArray away
cleanup:
if (clipRgn) DisposeRgn(clipRgn);
if (!okay) {
DisposeZoom(zoomArray);
zoomArray = NIL;
}
return(zoomArray);
}

Software Updates via MacUpdate

Kodi 15.1.rc1 - Powerful media center to...

Kodi (was XBMC) is an award-winning free and open-source (GPL) software media player and entertainment hub that can be installed on Linux, OS X, Windows, iOS, and Android, featuring a 10-foot user... Read more

Bookends 12.5.8 - Reference management a...

Bookends is a full-featured bibliography/reference and information-management system for students and professionals.
Access the power of Bookends directly from Mellel, Nisus Writer Pro, or MS Word (... Read more

Chromium 44.0.2403.125 - Fast and stable...

Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all Internet users to experience the web.
Version 44.0.2403.125:
This release contains a number... Read more

iMazing 1.2.2 - Complete iOS device mana...

iMazing (was DiskAid) is the ultimate iOS device manager with capabilities far beyond what iTunes offers. With iMazing and your iOS device (iPhone, iPad, or iPod), you can:
Copy music to and from... Read more

Audio Hijack 3.2.0 - Record and enhance...

Audio Hijack (was Audio Hijack Pro) drastically changes the way you use audio on your computer, giving you the freedom to listen to audio when you want and how you want. Record and enhance any audio... Read more

FontExplorer X Pro 5.0.1 - Font manageme...

FontExplorer X Pro is optimized for professional use; it's the solution that gives you the power you need to manage all your fonts.
Now you can more easily manage, activate and organize your... Read more

Calcbot 1.0.2 - Intelligent calculator a...

Calcbot is an intelligent calculator and unit converter for the rest of us. Featuring an easy-to-read history tape, expression view, intuitive conversion, and much more!
Features
History Tape -... Read more

MTR 5.0.0.1 - The Mac's oldest and...

MTR (was MacTheRipper)--the Mac's oldest and smartest DVD-backup app--is now updated to version 5.001
MTR -- the complete toolbox, not a one-trick, point-and-click extractor. MTR is intended for... Read more

LibreOffice 4.4.5.2 - Free, open-source...

LibreOffice is an office suite (word processor, spreadsheet, presentations, drawing tool) compatible with other major office suites. The Document Foundation is coordinating development and... Read more

Adobe Lightroom 6.1.1 - Import, develop,...

Adobe Lightroom is available as part of Adobe Creative Cloud for as little as $9.99/month bundled with Photoshop CC as part of the photography package. Lightroom 6 is also available for purchase as a... Read more

Bandai Namco has released Pac-Man Championship Edition DX on iOS and Android, which features the classic arcade gameplay that we've all grown to love.
Pac-Man Championship Edition DX can be enjoyed in much shorter bursts than the arcade versions... | Read more »

Angel Stone is Fincon's follow up to the massively successful Hello Hero and is out now on iOS and Android.
You play as a member of The Resistance, a group of mighty human warriors who have risen up in defiance of the Demon horde threatening to... | Read more »

The not exactly rumors were true and the birds are back. Angry Birds 2 has come to the App Store and the world will... well I suppose it'll still be the same, but now we have more bird-flinging options!
[Read more]
| Read more »

You Could Design Your Own Card for Chain...

If you've ever wanted to create your own item, weapon, trap, or even monster for Chainsaw Warrior: Lords of the Night, this is your chance. Auroch Digital is currently holding a contest so that fans can fight to the death (not really) to see which... | Read more »

Bitcoin Billionaire is Going Back in Tim...

If you thought you managed to buy everything there is to buy in Bitcoin Billionaire and make all the money, well you though wrong. Those of you who made it far enough might remember investing in time travel - and it looks like that investment is... | Read more »

Domino Drop (Games)

Domino Drop 1.0
Device: iOS Universal
Category: Games
Price: $1.99, Version: 1.0 (iTunes)
Description:
Domino Drop is a delightful new puzzle game with dominos and gravity!Learn how to play it in a minute, master it day by day.Your... | Read more »

Best Buy has iPad Air 2s on sale for up to $100 off MSRP on their online store for a limited time. Choose free shipping or free local store pickup (if available). Sale prices available for online... Read more

B&H Photo has the 13″ 1.6GHz/128GB MacBook Air on sale for $899.99 including free shipping plus NY tax only. Their price is $100 off MSRP, and it’s the lowest price available for this model.... Read more

Worldwide Tablet Market Decline Continues, Ap...

The worldwide tablet market declined -7.0% year-over-year in the second quarter of 2015 (2Q15) with shipments totaling 44.7 million units according to preliminary data from the International Data... Read more

The Apple Store has Apple Certified Refurbished iPad Air 2s available for up to $140 off the price of new models. Apple’s one-year warranty is included with each model, and shipping is free:
- 128GB... Read more

Updated Apple iPad Price Trackers

We’ve updated our iPad Air Price Tracker and our iPad mini Price Tracker with the latest information on prices and availability from Apple and other resellers.
Read more

Apple refurbished 2014 13-inch 128GB MacBook...

The Apple Store has Apple Certified Refurbished 2014 13″ MacBook Airs available starting at $759. An Apple one-year warranty is included with each MacBook, and shipping is free:
- 13″ 1.4GHz/128GB... Read more

Apple’s Education discount saves up to $300 o...

Purchase a new Mac or iPad at The Apple Store for Education and take up to $300 off MSRP. All teachers, students, and staff of any educational institution qualify for the discount. Shipping is free,... Read more

MacTech is a registered trademark of Xplain Corporation. Xplain, "The journal of Apple technology", Apple Expo, Explain It, MacDev, MacDev-1, THINK Reference, NetProfessional, Apple Expo, MacTech Central, MacTech Domains, MacNews, MacForge, and the MacTutorMan are trademarks or service marks of Xplain Corporation. Sprocket is a registered trademark of eSprocket Corporation. Other trademarks and copyrights appearing in this printing or software remain the property of their respective holders. Not responsible for typographical errors.

All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.