Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!uwvax!uwmacc!dubois From: dubois@uwmacc.UUCP (AntiNeophilus) Newsgroups: comp.sys.mac Subject: The Macintosh Blob Manager Message-ID: <624@uwmacc.UUCP> Date: Wed, 3-Dec-86 12:32:09 EST Article-I.D.: uwmacc.624 Posted: Wed Dec 3 12:32:09 1986 Date-Received: Wed, 3-Dec-86 21:53:17 EST Organization: Mundus Novum Lines: 393 This is the text of an article written for the local Macintosh user group newsletter. The Macintosh Blob Manager The Macintosh Blob Manager is a collection of routines and data types designed to allow objects of arbitrary appearance to be created, then controlled in highly specific ways. The principal use of the Blob Manager is to represent and process situations (or scenarios) involving associative transactions between sets of objects. These include interrogative or object management tasks such as puzzles, games, quizzes (verbal and pictorial), simple animation. Blobs may contain text, shapes, patterns, and so forth - in fact, anything you can draw on the Macintosh screen. Blobs may be enabled, disabled, frozen, thawed, dragged around or resized. A blob may be dragged on top of another blob to become associated with it, or cleared from the blob it is currently associated with. Blobs may be marked so that they are considered matched if certain other blobs are associated with them. Matched and unmatched blobs may be displayed in distinct ways to provide visual feedback. This article is primarily intended for programmers and is best read with a running copy of the Blob Manager Demo application in front of you. It presents an absurdly simplified overview and serves essentially as a brief introduction. More information may be found in "The Macintosh Blob Manager: A Programmer's Guide." [Note: the Demo that was posted a while ago differs very slightly from the description below.] Suppose a simple interrogative scenario is to be presented, such as whether a user knows the capital cities of a set of states. The names of the states and of the cities are easily displayed, but how should associations between them be represented? The user could be made to type in names - but that's contrary to the general spirit of Macintosh usage. Lines might be drawn between states and cities - but that can easily result in a messy display, especially if the elements of the sets are too numerous to be displayed in single rows or columns. Alternatively, the user might click on the city name and drag it onto the state name, so that the association would be represented by proximity. It would not be desirable for the state name to be covered up by the city name, though, since that results in a loss of display information. Instead, a region close to the state name could be used as an area onto which to drag the city name. This click-and-drag approach is the one implemented by the Blob Manager. It enjoys the following characteristics: o Highly graphic. o Consistent with Macintosh usage. Clicking and dragging are part of the canon of standard Macintosh operations. o Clean display. City names can be dragged to the appropriate states and be displayed in conjunction with them in such a way that the associations are clear, and such that the state names are not obscured. o The integrity of the display is not compromised by extraneous objects (such as lines), since all necessary information is on the screen. o The user is freed from the keyboard: all actions are entirely mouse-based. The Blob Manager allows the user to change his mind: he can drag the city name from one state to another, or clear it from a state altogether. City names can be swapped by dragging a city that's associated with one state onto another state associated with a city. The Blob Manager can provide feedback by assessing which associations are correct and indicating that visually to the user. This simple scenario illustrates one way of characterizing the Blob Manager, i.e., it provides a graphic representation of interrogative situations - questions and answers - together with mechanisms for association formation. The method it provides is consistent with a number of Macintosh applications that involve object movement in some form or another. Also, the goal of being intuitive and easy to understand is apparently satisfied: I am told that young children find it very easy to manipulate blob scenarios. Blob Anatomy Blobs are organized into blob sets: "no blob is an island, sufficient unto itself." Every blob in the set is represented internally by a blob record containing all the pertinent information about the blob. Although sets as mathematical entities are unordered, blob sets in particular have an ordering induced on them by the implementation (sets are treated as lists). When blobs are created, they are added to the end of their set, thus the i-th blob in a set - a concept with no mathematical meaning - is easily obtained. This allows treatment of blob sets as single-dimensional arrays. More complex data structures are easily induced on a blob set by making use of this fact. The overall area that a blob occupies is its general region. This region is divided into two subregions. One part is the drag region, which is the part of the blob that can be dragged onto other blobs (if it's a donor blob) or which can have other blobs dragged onto it (if it's a receptor blob). The part of the blob that is not in the drag region is denoted as the static region. Thus the static and drag regions normally are mutually exclusive and form a partition of the general blob region. Blob regions can be defined in the full generality of QuickDraw regions. The appearance of a blob is determined by what is drawn within the general region - the general image. Like the general region, the general image is composed of two parts, the drag image and the static image. In most respects, a region and its corresponding image may be referred to synomymously. The static region serves as a display-only region which is unaffected by user actions. It provides a means for display of information in a blob which remains unobscured when a donor is dragged onto it. In contrast, the drag region is under user control. When the mouse is clicked in the drag region of a donor blob and moved around, the Blob Manager responds by tracking it: an outline of the region follows the mouse until the button is released. For a receptor blob, the drag region is that region onto which a donor blob's drag region may be dragged - a kind of landing pad. Blob Imaging There are two methods for defining blob images. The first is to issue a set of QuickDraw calls as a picture definition, and install the picture into the blob record. Blobs imaged this way are picture blobs. Whenever the Blob Manager draws a picture blob, it replays the picture at the appropriate location, clipped to the region of the blob that is to be drawn. The second method allows blobs to arrange to have themselves passed to a procedure that knows how to draw them. Blobs imaged this way are procedure blobs. Picture and procedure blobs may be mixed within a scenario. The Blob Manager can be told to draw either or both the static and drag regions of a blob. The image drawn in the static region is always the blob's own image, clipped to the static region. The image drawn in the drag region is either its own or the drag region of any blob that was dragged onto it, in either case clipped to its own drag region. Each region is drawn either normally or dimmed. Each region has its own drawing mode, so each region can be drawn normally or dimmed independently of the other. By default, a region is dimmed by drawing it normally, then filling the region with gray in patBic mode. (The same method used to dim controls and menu items.) The reason for dimming blobs is explained later. Blob Transactions The kinds of operations the user may perform with the mouse are known as transactions, which the host effects by calling the transaction handling routine BlobClick when mouse clicks occur in a blob window. Because BlobClick is so fundamental to most programs using blobs, it may be configured to allow or disallow various types of transactions. This generality can be exploited to support a wide variety of scenarios. Two transaction types take place between donors and receptors. A donor blob may be dragged onto a receptor to become glued to it. The donor is then known as the receptor's glue blob (or glob for short). A glob may also be unglued from the receptor with which it is associated by double-clicking it, or by dragging it back to the donor it came from. The donor/receptor association is represented graphically by displaying a copy of the donor blob's drag image in the receptor blob's drag region. The donor drag image is scaled to fit the receptor drag region. Three other transactions types take place between receptors, although they all involve donors. Each is performed by dragging a glob from one receptor to another. Depending on the requirements of the host application, one of three things happens when this is done: (i) the glob may be transferred from the first receptor to the other; (ii) the glob may be duplicated, so that the donor glued to the first receptor also becomes glued to the second; (iii) if the second receptor also has a glob, the globs glued to the two receptors may be swapped. Each of these three types of transactions is allowed or disallowed under host control. Since each is performed by dragging a glob, precedence is enforced in the case where more than one of these transaction types is allowed. Swaps have the highest precedence, transfers the lowest. A receptor may only have one glob, so any glob a receptor has must be unglued in order for another glob to be glued to it. This implies another kind of transaction - replacement - that occurs implicitly when a glob is transferred or duplicated onto a receptor already having a glob, and during swaps. Replaces may be allowed or disallowed, which modifies the availability of the three explicit inter-receptor transactions. Note that if replacement permission is turned off, swaps are disallowed entirely, regardless of swap permission. The host application usually need not do much to engage in any of these transactions, beyond passing mouse clicks to the transaction handler. Since the transaction permissions are modifiable under host control, the particular requirements of a scenario can often be handled entirely by BlobClick simply by setting the permissions appropriately. Besides performing transactions, BlobClick also visually indicates "bad drags," which are defined as drags of blobs that don't end up on something that the dragged blob can be glued to. Such bad drags are indicated by zooming the blob outline back to the starting point of the drag. The transactions discussed so far are those initiated by the user with the mouse. The host may perform transactions independently of the user, for instance to clear a game board, show answers, or give hints. Transactions performed by the host are often indicated by zooming so that it's clear to the user what's going on. Donors can be zoomed, for example, to the receptors that they should be associated with, to show a set of answers. Hidden, Dimmed and Frozen Blobs This section discusses ways that visibility of blobs and their availability to transactions may be controlled by modifying display attributes. Visible/invisible blobs. The most basic kind of control that may be exerted over a blob is whether it shows on the screen or not. (Hidden blobs are not considered by the transaction handler BlobClick.) ShowBlob enables a blob and draws it. HideBlob disables and erases it. Dimmed blobs. Blobs or parts of blobs may be drawn normally or dimmed under application control. Dimming the drag region of a blob makes it unavailable to transactions regardless of the general transaction permissions. This is a fundamental Blob Manager concept. The mouse cannot be used to drag a dimmed donor to a receptor, and dimmed receptors cannot receive donors, have globs unglued from them, or engage in inter-receptor transactions. Blob glue counts. Donor blobs may be set to go dim automatically when they are simultaneously glued to a specified number of receptors. The participation of a visible donor blob in transactions is a function of its maximum glue count and its actual glue count. The maximum count is the upper limit on the number of receptors that the blob may be glued to simultaneously. This value is set at blob creation time and may be changed any time thereafter. (Blobs may be given an infinite maximum glue count.) The actual glue count is equal to the number of blobs the blob is glued to at a given moment. A donor goes dim when it has been glued to as many blobs as its maximum glue count allows, and becomes unavailable for further glue or duplication transactions. Its drag region does dim to signal that fact. If a donor is unglued from one or more of the receptors it is glued to, it becomes available for dragging again; its drag region is then undimmed as well. Appropriate redrawing and/or dimming/undimming of blobs involved in user-initiated transactions is automatic. Frozen/thawed blobs. Sometimes it is desirable to make blobs unavailable for transactions without hiding or dimming them, for example if certain board positions that are not legal moves are to be removed from play without changing the way they look. This is accomplished by freezing the blobs, which does not change their display state, but makes them unavailable for hit-testing or transaction operations. A frozen blob may be thawed to restore it to its state prior to being frozen. This includes restoring its display state, if that was changed after the blob was frozen. For instance, the implementation of tic-tac-toe must allow users to drag the X-blob and the O-blob onto the board, but only one symbol is legal for each player. While each player takes his turn, the other player's symbol could be frozen to make it unavailable. Blob Matching, Visual Feedback That receptor blobs may be considered as questions to be asked implies a mechanism for assessing correctness of answers. This is done by specifying, on a per-blob basis, which other blobs are considered a match for it. The Blob Manager has mechanisms for testing whether individual blobs or blob sets are matched or not. The test is usually made after calling BlobClick. If BlobClick performed a transaction resulting in a termination state (all answers correct, game over, etc.), this is often detectable with a single Blob Manager call. It is sometimes desirable to provide feedback during problem solving activities, and the Blob Manager can visually indicate the state of blob matches. For example, a user may wish to know which answers are correct. The BlobFeedback routine provides a mechanism for graphically indicating which in a set of blobs are matched and which are not. Typically, matched blobs are dimmed while unmatched ones are displayed normally, or vice versa. Blob Hit-testing, Tracking and Dragging For many scenarios, the BlobClick routine is entirely sufficient to handle all transactions. However, should the host itself wish to determine which blobs mouse clicks fall in, or do tracking or dragging operations itself, it can do so. FindBlob may be used to determine which, if any, of a set of blobs a mouse point lies in. TestBlob determines whether a mouse point is in a given blob or not and returns a part code to indicate whether the point is in the static region or the drag region, or zero to indicate that the point is not in the blob. When the mouse button is pressed in a blob, the Blob Manager may be told to drag around a gray outline of the blob or part of the blob. The blob may be dragged to the point where the mouse is released, or the Blob Manager may be told to simply return the result of the blob drag. The tracking routines track the blob by making an outline of it follow the movements of the mouse. In constrast, BTrackMouse is used to track whether the mouse remains within a stationary blob when the mouse moves. This is analogous to TrackControl. It takes a blob, a starting point and a part code. The region specified by the part code is highlighted (by inverting it) whenever the mouse is inside it. If the mouse is released inside the region, BTrackMouse returns true. Conceptually, this operation is identical to the way push buttons are tracked when clicked with the mouse. Since the appearance of blobs is less constrained, one can easily implement "controls" of highly arbitrary appearance. (Several Blob Manager Demo scenarios have vertical buttons - they're actually blobs.) More on Transactions Often illegal moves can be ruled out by freezing certain blobs or by setting the transaction permissions appropriately. For instance, in tic-tac-toe, all illegal moves can be prevented before the user clicks the mouse simply by freezing every square on the board that is already occupied. Not every situation is so simple, however, and in such cases it is desirable to know something about transactions while they are actually occurring. For example, in a game of checkers, illegal moves cannot be prevented by freezing certain board positions, because the set of legal moves is dependent on the piece the user wishes to move. If it were known which piece the mouse was clicked in and which square of the board it was dragged to, the legality of the move could be assessed and the move either allowed or disallowed before the piece was actually moved. In a game of solitaire, only certain cards may legally be laid on any given card, but the set of cards that may be placed on that card varies. Knowing which cards the user planned to move, and where, is information that could be used to disallow transactions which might be legal according to the general transaction permissions, but illegal according to the particular semantics of the game. To this end, BlobClick allows the host to specify an advisory filter function to cope with scenarios that may be too complex to handle with the normal mechanism. BlobClick calls this filter whenever the mouse is clicked in a blob and when a blob is dragged onto something to which it can be glued. The advisory function examines its arguments, takes whatever action it deems appropriate, then returns a boolean value indicating to BlobClick indicating whether to continue processing or not. Installation of an advisory function allows the host access to information about transactions in progress, so that it can, in effect, "call the shots" on transactions without having to perform the mechanics of hit-testing, dragging, etc. The advisory function does not extend the scope of allowable transactions or override the general transaction permissions. It is not even called unless BlobClick considers the action done by the user to be legal according to those permissions, so the advisory can only further restrict the user's actions. Thus if a donor is dragged to a receptor already having a glob, but replace permission is turned off, the advisory is called only when the donor is clicked, not when the donor is dragged to the receptor (BlobClick wouldn't consider replacing the glob that is already there, anyway). ---- The Blob Manager is public domain. It is provided in source form, with documentation. The Blob Manager was written with LightspeedC (tm). The official example of Blob Manager programming is the Blob Manager Demo (included in the standard distribution). The Demo runs on top of the TransSkel transportable application skeleton (public domain, same author). Contact one of the addresses below for more information. U.S. Mail: Paul DuBois 1220 Capitol Court Madison, WI 53706 USA UUCP: {allegra, ihnp4, seismo}!uwvax!uwmacc!dubois ARPA: dubois@unix.macc.wisc.edu dubois@rhesus.primate.wisc.edu --- Paul DuBois UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois | ARPA: dubois@easter --+-- dubois@rhesus | | "What is lacking cannot be counted." - Solomon the cladist (Ecclesiastes 1:15)