A.1 Executive Summary

Drag and drop is a convenient, powerful, general purpose accelerator for transferring data within and between applications. This specification establishes conventions for the user interface of the drag and drop mechanism. It is intended to guide the implementation of drag and drop for OpenWindows Version 3.0.1 or greater, and to guide application developers toward consistent uses of the technique. It does not describe implementation details of the drag and drop mechanism, nor does it describe the API.

This document includes descriptions of:

• the kinds of objects that can be dragged
• the meanings of dropping objects on specific locations (such as on a window header, on a pane in a window, or on a drag and drop target)
• the differences between dragging with and without the Duplicate modifier key held down
• the visual feedback associated with the stages of a drag and drop operation
• how the process of data translation appears to users
• how users can cancel drag operations in progress, and undo completed drag 1 operations

---

1. In this document, drag and drop operations are sometimes referred to as drag operations and drags.

• how error messages are presented to users

A.2 Introduction

A.2.1 Classic Examples

Drag and drop is a technique for manipulating data and applications by directly manipulating graphical objects on the display screen. It has become a standard accelerator on the SunSoft desktop for transferring data between applications and for moving data around within an application. A classic example of the use of drag and drop is to move documents around in the directory hierarchy. For example, in File Manager you can move a document into a folder by dragging a document glyph and dropping it on a folder glyph. Technically speaking, the document is the source object, and the folder is the destination object. First you press and hold the Select mouse button while the pointer is on the document you want to move (the source) and then you drag it onto the folder glyph (the destination) and release the mouse button.

In addition to dragging documents between folders in File Manager, you can also drag documents from a File Manager folder into the wastebasket to delete them, or onto Print Tool to print them. See Figure A-1. Whereas moving documents among folders in File Manager or from a folder to the wastebasket involves only one application (File Manager), dragging documents to the Print Tool involves the transfer of data between two applications, File Manager and

Print Tool. In other words, in the latter case the source application and the destination application are different, whereas in the former cases they are the same.

Figure A-1

A.2.2 Drag and Drop as Cut and Paste

Another classic use of drag and drop is as an alternative to the Cut and Paste commands. For example, Text Editor allows you to move selected text from one document to another either by using the Cut and Paste commands, or by using drag and drop. To use drag and drop, you follow these steps. Before you begin, you need to have the two documents loaded into Text Editor, and visible in two windows. Then you select the part of the first document that you want

to move. Next you press the Select mouse button on the selection, and drag it to the location where you want to insert it in the other document. Releasing the mouse button completes the drag and drop operation. See Figure A-2.

Figure A-2

Although drag and drop is often used as an alternative to Cut and Paste, as described above, the two techniques have subtly different effects. First, whereas the Paste command inserts the source object at the caret in the destination document (replacing the selection if there is one), drag and drop inserts it at the hot spot of the pointer. Second, drag and drop does not involve the clipboard, whereas Cut and Paste do. Third, after a drag and drop operation the newly inserted text is selected, whereas after a Paste it is not selected.

A.2.3 To Cut or To Copy?

In the example above, drag and drop was used as an alternative to Cut and Paste. However, if the user had held down the Duplicate modifier key¹ during the drag operation, the source would have been copied. As a result, the drag and drop operation would be analogous to Copy and Paste rather than Cut and Paste.

A.2.4 Where We Are Headed

As these examples indicate, the drag and drop technique is used in a variety of different ways by OPEN LOOK applications. It has proven to be a convenient, powerful, general purpose accelerator for transferring data within and across applications. To exploit the paradigm to its fullest, we need conventions for its use so that applications will use it in similar ways, and consequently, users will know what to expect of it. Conventions are necessary for everything from the meaning of dropping onto an iconified application base window (a mini-window), to the feedback that appears when the user attempts a drop in an inappropriate place.

The following sections of this document describe the details of the user interface for drag and drop. They include a formal definition of drag and drop, and a description of the kinds of operations that applications may use drag and drop for. They also specify the meaning of dragging with and without the Duplicate modifier key held down, and the meanings of dropping on specific types of destination objects. Finally, they specify the visual feedback associated with the stages of the drag and drop operation, and describe how a variety of special conditions should be handled.

A.3 Formal Definition

Technically speaking, drag and drop is a gestural technique for manipulating 2 objects, with the following characteristics:

---

1. The Duplicate modifier key is the Ctrl key by default.

2. The term object is used in the loose, generic sense in this document.

• The source is indicated by initiation of the drag operation on an object that typically has been selected, or that will become selected as the drag operation begins.
• The drag operation is initiated by pressing and holding down a mouse button while dragging the mouse. Dragging the mouse involves moving it by five pixels or more.¹
• Following initiation of the drag operation, a drag mode persists in which the user indicates a continuous path from the source to the destination.
• The drag operation terminates when the user releases the mouse button.
• The destination is indicated by the pointer position at the end of the drag operation. More specifically, the destination is indicated by the location of the pointer's hot spot when the user releases the mouse button.

On the SunSoft desktop, drag and drop is defined as an accelerator--anything that you can do using drag and drop you should also be able to do in another way, often by selecting commands from menus.

A.4 The Source

Any object that is selectable can potentially be dragged, excluding, of course, selections in most controls (such as exclusive and non-exclusive settings and menus). Typically, the source is a data object, such as a document or a text selection, or a container of data objects, such as a folder.

When the source object is a text selection, a data object, or a container of data objects, the source is the primary selection. After the drag operation has completed, the new object at the destination location is the primary selection. For example, if you drag a text selection from one window to another, after the drag operation the text that has been inserted at the destination location is selected.

---

1. Users should be able to adjust the drag threshold through a workspace property.

A.4.1 Multiple Source Objects

You can drag many different source objects in a single drag operation, provided that you can create a selection that includes all the objects. When the primary selection includes objects in a window, this naturally restricts you to dragging objects only from a single window, since the primary selection cannot span windows.

If the source objects have a natural logical ordering in the source application, the drag operation should preserve the ordering. For example, if the source objects are document glyphs that are displayed in the source application organized by filename, the drag operation should order them alphabetically by filename. However, the destination application should not presume that the source objects it receives are ordered in any way.

A.4.2 Windows as Source Objects

Open windows and iconified windows (that is, mini-windows) also may be source objects in drag and drop operations, however, these drag and drop operations are atypical in several regards.

First, when you drag a window it does not become selected. Because the window is not selected, you can drag it without losing the current primary selection. So, for example, you can make a selection in a window; then drag the window to reposition it; and your selection in the window will still be there.¹

Second, you can't duplicate a window by holding down the Duplicate key when starting a drag operation. Whenever you drag an open window or a mini-window, the effect of the drag action is to move the window, not to clone it.

Third, when you are dragging an open window or mini-window, the only place you can drop it is onto the workspace. In other words, when a mini-window or an open window is the source, the only legal destination is the workspace. Of course, you can drop one window onto another, because our workspace supports overlapping window placement.² However, even in this case the destination is the workspace. That is, the overlaid window is not the destination, the workspace is.

---

1. In the future we may identify other cases where it is useful to be able to drag an object without selecting it. However, presently only open windows and mini-windows can be dragged without being selected.

Fourth, when you drag an open window or a mini-window, the mouse pointer does not change into one of the pointers that are typically used for drag and drop operations (see Figure A-6 on page A-22). The normal pointer was chosen because users are unlikely to view dragging open windows and mini-windows as drag and drop operations. And due to all of the restrictions on dragging open windows and mini-windows, users should not view dragging a window as a drag and drop operation.

A.5 The Destination

The destination of a drag operation is determined by the location of the pointer's hot spot at the time the user releases the mouse button. If the source object is a data object or a collection of data objects, the destination may be a data object; a container of data objects such as a directory (i.e., folder); the workspace; a mini-window; or a location in an open window, such as a data pane, a text field, or a drag and drop target. Drag and drop targets are a new type of graphical element, whose purpose is to support drag and drop operations. They are described in a following section of this document. If the source object is a mini-window or an open window, the only allowed destination is the workspace.

The legal source and destination combinations are shown below.

Table A-1

Source	Data Object/Container	Destination Mini-Window	Open Window	Workspace
Data Object/Container	Yes	Yes	Yes	Yes
Mini-Window	No	No	No	Yes
Open Window	No	No	No	Yes

---

2. There is one exception to this. You cannot drop a mini-window onto an open window. More specifically, you cannot terminate a drop when the source is a mini-window and the hot spot of the pointer is within the border of an open window. If you attempt such a drop, a Notice will be presented which will tell you the drop operation is not allowed, and the drop will be terminated.

A.5.1 The Drop Method

The primary purpose of the drop method is to specify the processing that the source object undergoes at the destination. That is, the drop method determines the effect of the drag and drop operation on the destination. The application that owns the graphical element underneath the pointer at the time of a drop (the destination application) identifies the drop method. The destination may use different drop methods depending on what type of object the source is and depending on where the user dropped the source object.

To ensure conformity among applications and to make it easy for users to guess what the results of a drag operation will be, we have established guidelines for the drop methods applications may use with different parts of the workspace. These guidelines specify which standard elements of the workspace can be used as destinations, and they describe appropriate types of drop methods.

A.5.2 Dropping onto Specific Locations

Text Fields and Text Panes

When you drop a source object onto a single-line text field, multi-line text field, or text pane, the source object should be inserted into the destination text at the position of the pointer's hot spot. If the source object is a text selection, then the text selection is inserted, whereas if the source object is a named object (such as a document), the name of the source object is inserted.

Naturally, source objects that are neither named objects nor text selections cannot be dropped onto text fields.

Non-Text Panes

As is the case with text panes, when the user drops a source object onto a non-text pane, the source is inserted into the destination object. However, whereas in a text pane the source is always inserted at the pointer's hot spot, in a non-text pane the destination application has several options to choose from. The destination application may choose either to insert the source object at the pointer's hot spot, or to:

• insert the source object at a location that depends solely on characteristics of the source object

Calendar Manager processes mail messages dropped on it in this fashion. If you drop a mail message onto an open Calendar Manager window, and the mail message contains a correctly formatted appointment, Calendar Manager will insert the message into the calendar at the appropriate date and time.

• place all source objects at a single location in the destination pane

  For example, imagine a graphical cartridge tape manager that has a data pane that displays glyphs for the files on the tape. Imagine that you can drag a document from File Manager onto the Tape Manager pane to add the document to the tape. Because tapes are sequential media, regardless of where you drop the document in the pane, the document file is added to the end of the tape.

• apply processing specific to the glyph the source object was dropped onto

  For example, File Manager's Path Pane and Folder Pane behave this way. If you drop a document onto a folder in either pane, the document moves into the folder you dropped it on. In contrast, if you drop a document onto the background of the Folder Pane, the document is moved into the directory displayed in the pane.

Scrolling Lists

A scrolling list may accept a source object and insert it as a new entry in the list. The destination application may insert the source into the list either:

• 1 · at a location that depends on the pointer's hot spot
• at a location that depends on characteristics of the source object

  For example, in an alphabetical list the source object could be inserted alphabetically by name (or by content if the source object is a text selection).

• at a single fixed location

  For example, when you drop a document onto the Print Tool scrolling list, the document is inserted at the end of the queue.

---

1. By default, when an object is dropped on a list item, the source object is inserted above the item it was dropped on.

Scrolling lists that allow users to drop items into the list, and/or to drag items already in the list, should have a small icon to the left of each item in the list.

Mini-Windows

When you drop a source object on an iconified application base window (a mini-window), the result of the drop should match the results of a drop method that the open base window supports. If the base window supports more than one drop method, the mini-window should use the drop method that is most closely associated with the base window as a whole. For example, if the application supports a load drop method, that drop method should be supported by the mini-window.

Naturally, a mini-window cannot use a drop method that inserts the source object into a data pane at the pointer's hot spot (since the pointer's hot spot is over the mini-window, not over a data pane). For example, a drop onto the Text Editor mini-window cannot correspond to a drop onto the Text Editor base window's text pane, because the results of a drop onto the text pane depend on the precise location of the pointer's hot spot in the text pane.¹

Applications should follow these guidelines in choosing a drop method for a mini-window:

• If the associated open window uses only one drop method, and the drop method does not insert the source object at the pointer's hot spot, then that drop method should also be used for the mini-window.
• If the associated open window supports more than one drop method that does not involve an insertion at the pointer's hot spot, then the mini-window should use the drop method that is most closely associated with the base window as a whole.
• If the associated open window has a drop method which loads the source object into the application (replacing the data there) that drop method should be used for the mini-window.
• If the associated open window allows drops onto its header, dropping onto the header should have the same effect as dropping onto the mini-window.

---

1. Do not use the caret as a substitute for the pointer hot spot.

Window Backgrounds

Applications may not allow objects to be dropped onto the backgrounds of open windows, except, in some cases, onto the window header.¹ In addition to the header, the background of a window includes:

• the footer
• areas to the left and right of data panes, excluding areas immediately adjacent to scrollbar drag boxes and cables
• the backgrounds of control areas

When an application wants to provide a drop method that there is no obvious receptacle (i.e., destination object) for, the application should use a drag and drop target in a control area. For example, when an application supports a load drop method, a drag and drop target should be provided for it. Applications that don't have control areas may use their window headers instead of drag and drop targets.

The Workspace

Dropping an object onto the workspace should not cause the object to transform, such as becoming a mini-window for a running application (which is what File Manager does).

In the future, it may be possible to drop data objects onto the workspace and have them appear to rest on the workspace. However, because there is presently no mechanism in place for displaying data objects on the workspace, this guideline represents a long-term objective. It is included here as a hint to applications about how we intend to use the workspace in the future. Also, it is intended to preclude applications from using drops onto the workspace for other purposes.

---

1. Drops onto the background are not allowed for two reasons. First, a background should be a neutral zone, which means that it should not have magical properties, such as the ability to accept dropped objects. Second, if a background had a drop method and elements on it had other drop methods, it could be difficult for users to predict the effects of a drop. In cases where a destination doesn't have a clear boundary, as a text field doesn't, it would be hard to know where one destination object ends and the other begins.

Drag and Drop Targets

If an application wants to support a drop method and there is no obvious destination receptacle for the drag and drop operation, it should use a drag and drop target. Such obvious receptacles include text panes, single-line text fields, glyphs displayed in non-text panes, and scrolling lists, among others.

What Drag and Drop Targets Are. A drag and drop target is a rectangular graphical element, typically located in a control area, whose primary purpose is to serve as a destination for drag and drop operations. See Figure A-3.

Figure A-3

A typical use of a drag and drop target is as a receptacle for dropping an object to be loaded into the destination application. Imagine an editor window that has a drag and drop target in its control area. Imagine further that the data pane is displaying The_Simpsons, the file currently loaded in the editor. Imagine that this editor window supports two types of drag and drop operations, one which uses the text pane as a destination, and one which uses the drag and drop target. If you drag a document--call it Bart--from File Manager and drop it onto the text pane, Bart will be inserted into The_Simpsons at the location where you dropped it. If instead of dropping Bart onto the text pane, you dropped it on the drag and drop target, Bart would replace The_Simpsons as the document presently loaded. If you had unsaved edits in The_Simpsons, the editor would present a Notice window asking whether you want to save them before closing The_Simpsons.

As a secondary feature, some drag and drop targets contain images which can themselves be dragged. That is, the images can be source objects in drag operations. Consider again the Text Editor example above. Imagine that the drag and drop target contains a glyph which can serve as a source object that represents the document presently loaded. For example, if Bart is currently loaded, you can drag the Bart image out of the drag and drop target and onto

the Print Tool to print Bart. This action prints the version of Bart which currently appears in the window (which may contain unsaved edits), and does not unload Bart from the Text Editor. See Figure A-4.

Figure A-4

Windows are not required to include a drag and drop target. When an explicit drag and drop target is used, there should typically be only one per window or, at most, one per control area. Multiple drag and drop targets should be used only when the control areas in which they appear have explicit borders separating one panel from another. The drag and drop target always applies to the entire window or control area in which it appears. In particular, drag and drop targets should not be used to load data into single-line text fields or other individual controls, since these objects can accept drops directly when appropriate and do not require explicit targets of their own.

An explicit drag and drop target may, however, be included as an alternative to the primary drop site in a window or control area - provided there is a clear primary drop site that applies to the window or control area as a whole. In such cases, the explicit target will indicate to the user that drops are permitted when the presence of a drop site might not be sufficiently obvious based on the appearance of the drop site itself. An application whose primary drop site is a scrolling list, for example, might choose to provide a drop target to indicate that drops are permitted. In such cases, dropping on the drag and drop target should have the same effect as dropping on the primary drop site. Because it will typically be smaller and thus more difficult for the user to hit, the alternative drop site should only be added if the primary drop site will not be apparent to the user.

Introducing a drag and drop target to an existing application should not cause larger, more accessible drop sites to ignore drop requests. For example, many read-only data viewing applications permit users to drop files onto their data panes for immediate display. This method should continue to be supported for backward compatibility with established conventions even after a drag and drop target is added, because it is easier for the user to point at the data pane than at the drag and drop target and because drops over read-only data panes do not create any ambiguity over whether the data being dropped should replace, or be inserted into, the current data.

Visual Appearance of a Drag and Drop Target. As Figure A-3 on page A-13 shows, a drag and drop target appears to be a box whose open top is flush with the screen. The sunken appearance signifies that the object is a receptacle. Drag and drop targets have two standard sizes (see "Drag and Drop Target Engineering Specification" on page A-31). The smaller standard size allows the drag and drop target to be added to the control area that typically appears at the top of an OPEN LOOK base window without increasing the normal height of the control area. Drag and drop targets should use the smaller standard size whenever the control area contains only one row of buttons. The larger standard size provides a target that is somewhat easier to drop on and that is also large enough to permit the display of an application-specified image inside the target's frame. The larger standard size should be used whenever there is sufficient room in the control area containing the drag and drop target. Drag and drop targets can be created in arbitrary sizes if necessary, but the two standard sizes should be used whenever possible, since the size and proportions of the target are important means of identification.

Like other standard OPEN LOOK controls, drag and drop targets should appear only in control areas; they should never appear in data panes. The drag and drop target is typically located in the upper right-hand corner of the control area. When it is located in a control area above a data pane, the drag and drop target should be right-aligned with the right edge of the data pane. If the drag and drop target has a textual label, the label should appear to the left of the drag and drop target in the standard bold font and be followed by a colon. The bottom of the drag and drop target should be positioned slightly below the baseline of the text.

When a window containing a drag and drop target is resizable, the target should be positioned relative to the top and right-hand edges of the window or control area. The drag and drop target should remain in the same relative position whenever the window is resized to ensure its continuous visibility

when the size of the window is reduced. If the application permits its window to be resized such that the drag and drop target would extend into the space occupied by another control, the drag and drop target should appear to overlap the other control.

Drag and Drop Target Content Images - In their normal states, some drag and drop targets are empty, whereas others contain object images. A drag and drop target is ordinarily empty if it doesn't allow objects to be dragged out of it. These empty drag and drop targets contain an image only while they are processing dropped objects. This image has a grayed-out, or busy appearance. Refer to the center figure in Figure A-5. Once the drop has finished being processed, the object image and the busy feedback vanish and the drag and drop target is empty again.

In contrast, if a drag and drop target allows an object to be dragged out of it, there is an object image inside the drag and drop target at all times that dragging-out is possible. For example, in the editor example described above, the drag and drop target always contains an object image, except when there is no document presently loaded in the window. The default content image is a series of horizontal lines spaced evenly across the receptacle. Applications may choose to provide other, customized images. The object image is overlaid with the standard OPEN LOOK busy feedback while a drop is being processed. After the drop completes, the object image resumes its normal appearance. Refer to the right figure in Figure A-5. When a drag and drop target is inactive, the borders of the box as well as its content and label should be dimmed.

Figure A-5 Drop Targets: Empty, Busy, and Containing an Image

Applications may occasionally need to display an object that can serve as the source for a drag operation, but which nevertheless cannot serve as a legal drop site. The standard, "sunken" drag and drop target should not be used in

these cases. The recommended solution is to display a glyph that represents the data and serves as a source for drag operations. This drag source image should appear in one of the standard sizes defined for use with the drag and drop target and should be positioned according to the same set of rules. The drag source image should be surrounded by a one-pixel border line that matches the interior dimensions (i.e., the "sunken" rectangle inside the bevel) of an appropriately sized drag and drop target. In color implementations, the border should be a standard "chiseled" line comparable to the border of a control area.

Drag and drop targets (and drag sources) appearing in the smaller standard size should normally use the default content image (see Figure A-5) because the available imaging area is not large enough to make distinctions between images representing different data types practical. If an application-specified content image is required, or if space for a larger target is already available, the drag and drop target should use the larger standard size, which is designed to accommodate a standard (32 x 32) File Manager document glyph for the data in the window. If the content image is used to represent a specific type of data object, it should use the same image that appears in the File Manager for data objects of that type. (The application should query the Classing Engine for the appropriate glyph rather than using a hard-coded image, since users can change the glyph assigned to a particular type of data object at any time.)

A.6 To Copy or Not to Copy?

Drag and drop operations transfer an object. Transferring an object may mean relocating a document in the file system; loading a document into an editor; printing a document; inserting a text selection into a document; or any number of other actions determined by the characteristics of the source object, the nature of the destination application, and where in the destination application the source object is dropped.

You can use drag operations simply to transfer a source object, or to duplicate the source object and transfer the duplicate. To support these two forms of drag and drop, there are two types of drag operations which differ in whether the user holds down a modifier key while initiating the drag. The standard form of drag and drop is the unmodified form, where the user does not hold down a modifier key. In this section this form is referred to as unmodified-drag. The second form involves holding down the Duplicate modifier while

initiating the drag operation, and is referred to as Duplicate-drag. Whereas Duplicate-drag always copies the source object, an unmodified-drag may or may not, depending on what is most intuitive in the current context.¹

A.6.1 Unmodified Drag

Because users are most likely to learn the unmodified form of drag and drop first, and to use it when they are exploring new drag and drop actions, it has been designed to do the most obvious thing in a given situation. That is, it either does or does not duplicate the source object depending on what the source object is and what the destination is doing with it.

Typically, when a drag operation is relocating data, the source object is not duplicated. For example, when you drag a document from one folder to another in File Manager, it is clear that you meant to reorganize your directories, and the document is not duplicated. Similarly, when you drag a document from a folder onto the wastebasket, it is clear that you meant to relocate the document to the wastebasket, and in this case as well the document is not duplicated. Similarly, when a drag operation loads data into an application, it does not duplicate the data.²

In contrast, in many cases when a drag operation carries data from one application to another, the data are transformed, and the user would typically prefer that the operation not affect the original source object. For example, when you drag a document from the File Manager onto the Print Tool, the data are transformed into a hardcopy document, and you are not likely to want to lose the original document. As another example, consider dragging a message from Mail Tool onto Calendar Manager. This action transforms the mail message into a scheduled appointment, assuming the mail message is formatted correctly. In this case as well, it is not clear that a user would be happy to lose the original mail message.

Note that both the source and destination applications play a role in determining whether or not an unmodified drag operates on a duplicate of the source object. The impact of the drag operation on the original source object in the source application depends on where the user drops it. For example,

---

1. Another type of drag operation may be added in the future to support link creation.

2. In fact a copy of the source object is loaded. However, from the user's perspective he or she is operating on the original object, since the original source object's name appears in the destination application header, and by default changes will ultimately be committed to the original object.

imagine that you drag a document from a File Manager folder. The source may or may not eventually be removed from the folder, depending on whether you drop the document on Print Tool, or on the wastebasket, or onto a load drag and drop target in Text Editor. When a drop has been completed, the destination application advises the source application as to whether the source object should be removed from its original location.¹

Naturally, the successful completion of the drop is a necessary condition for removing the source. That is, any time that a drag and drop operation does not complete successfully, the source will not be removed.

A.7 Loading Data

In many cases, using drag and drop to load a file into a destination application is identical, in effect, to loading the file via more conventional means (such as by choosing "Open" from the application's File menu). Specifically:

• If there are any unsaved modifications to the currently-loaded file, a Notice window is presented that gives the user the opportunity to save the changes.
• The currently-loaded file is closed and the new file is loaded.
• The newly-loaded file's name and path are displayed in the window header following the application name.
• After the user modifies the newly-loaded file, he or she can save the changes back to the original file, typically using "Save" in the File menu.

In other cases, a load resulting from a drag and drop operation may differ in one or more regards from loading a file via more conventional means. First, occasionally, such as when the file is dragged from a File Manager running on a remote machine with an inaccessible file system, only the filename (not the path) is accessible. In such cases the window header should display the filename and the name of the application the file came from. Specifically, the window header should display:

Current Application -- Filename From Source Application

---

1. Generally, the destination application should recommend that the source be removed only when it is clear that the user intended to relocate the source object. The original source object should be left behind whenever it is not intuitively obvious that the user would expect the operation to remove the source.

For example, if you were to drag a file called Lisa from a File Manager running on a remote machine to a Text Edit application window running on the local machine, the window header should display:

Text Edit -- Lisa From File Manager

Second, occasionally it may not be possible to save the modified document back to the original file. For example, if you had dragged the file from a File Manager running on a remote system, and the remote File Manager application then died, you could not save the file back. In cases such as this the "Save" item in the File menu should be inactive (i.e., grayed out). Users presumably will still be able to use the "Save As" command to save the file to the local file system. They may also be able to restart the remote File Manager and drag the file into it.

Third, unlike the more conventional methods of loading files, when you are loading a file via drag and drop you have the option to duplicate the original source file, and then load the duplicate. If you press the Duplicate key and then perform a drag operation whose drop method is a load, the source object is duplicated in the source application and then the copy is loaded into the destination application. Ordinarily, if the original source object was named "Bart", the duplicate is called "copy_of_Bart". However, if the original source object name begins with "copy_of_", or if there is already a file named "copy_of_Bart" in the current directory, then the duplicated name begins with the string "copy2_of_", and so forth.

A.8 Data Format Conversion

Frequently the source object is in a data format that differs from the destination's data format. For example, imagine that you drag some text from Text Editor into a painting application's window and drop it onto the painting canvas. Whereas Text Editor stores data in ASCII format, the painting application might store it in Postscript format. In order for the painting application to insert the source object into its document, the source must be converted from ASCII to Postscript.

Ideally, when a drop entails data format conversion, the conversion should occur transparently. That is, the user shouldn't even need to know it happened. However, in some cases the destination application may not be able to decide

how to handle the source data format. In those cases, the destination application should let the user choose among alternative formats listed in a Notice window.

A.9 Handling Multiple Source Objects

Typically, when the destination receives multiple source objects during a single drag and drop operation, it should treat them as independent drag and drop events. However, they may be treated as a single, atomic event in cases where:

• undesirable results would be obtained if all the source objects were not successfully processed by the destination; and
• the destination can reverse the effects of any processing already completed at the time that a failure occurs.

When the destination application treats multiple source objects as independent drag and drop events, it should present a Notice window for each source object that is not successfully processed. The user may terminate processing of all the source objects by pressing the STOP key (once).

A.10 Visual Feedback

A.10.1 While Dragging

When you begin a drag operation, the pointer changes shape and an image of the source object is attached to the pointer to provide feedback that a drag and drop operation has begun. As you drag the pointer over different graphical objects, it changes shape to indicate whether a drop is allowed. In addition, the prospective destination object may animate to provide visual feedback about whether it can accept the source object. For example, a folder might open to show that it can accept the source object.

The visual appearance of the pointer, and the visual image of the source object that the pointer drags along, differ depending on whether the source object is a text selection or not. The two sets of visuals are described in the following sections.

While Dragging Data Objects and Containers

When you begin dragging a data object or a container of data objects, the pointer changes to either the move pointer or the copy pointer (see Figure A-6). It changes to the move pointer if you initiated an unmodified-drag, and to the copy pointer if you initiated a Duplicate-drag.

Figure A-6

In addition to changing the shape of the pointer, the source application should attach to the pointer a graphic image to represent the source object. See Figure A-7. The source object image should be a relatively compact representation of the source that fits around the pointer. If the source object itself is a small graphical object, the shape of the image that is dragged should be the same as the shape of the original source object. If the source object has no obvious visual representation or is too large to be previewed in its entirety during the drag operation, an image that is roughly the size of a File Manager glyph should be designed to represent the source object.

Figure A-7

The source image should be transparent, and should not have much internal detail, so that users can see through the source image to the object underneath the pointer's hot spot. The move or copy pointer should be placed on the source

image in a way that: (a) the hot spot of the pointer is as near as possible to the middle of the source image; and (b) the "tail" of the pointer is not obscured by the outline of the source image. When a user drags multiple source objects at once, a representation of the collection of source objects should surround the pointer

Feedback About Prospective Destinations. Whenever possible, when you drag the pointer over a graphical object on the screen during the drag operation, the drop allowed or the drop not allowed symbol should be added to the pointer. See Figure A-8. To ensure that these symbols will be legible when overlaid onto the image being dragged, an area equal to the size of the symbol should be cleared in the center of the source image before the drop allowed or drop not allowed symbol is added. The object under the pointer may also change its appearance to indicate that it can accept the source object.

Figure A-8

In some cases applications may not be able to predict with certainty whether a drop on the destination object will succeed or not. However, applications should try to be as accurate as possible. So long as the feedback is typically accurate, and errors seem like reasonable errors, users will forgive occasional misinformation.

With respect to the drop allowed and drop not allowed pointers, three areas of the screen are considered neutral: the workspace itself, window and control area backgrounds in general, and the background of the data pane (if any) from which the drag operation was initiated (all areas of the data pane except those explicit graphical objects that are either legal or illegal destinations for a drop are considered part of its background). With one exception, the pointer image always changes to the move or copy pointer while it is over these areas. The exception to the rule is: If an application supports drag and drop actions

within a single window, but not between windows, then the pointer should change to the drop not allowed shape as soon as the pointer leaves the source window.

While Dragging a Text Selection

When you begin dragging a text selection, the pointer image changes immediately to the text move or text copy pointer, depending on whether you are holding down the Duplicate key. These pointers include a rectangular area containing at least the first three characters of the text selection as a "preview" of the data being dragged. If the selection contains more characters than will fit within the rectangle, a dimmed More arrow follows the characters in the rectangle.Text Move and Text Copy Pointers.

Figure A-9 Text Move and Text Copy Pointers

The text move and text copy pointers in are neutral pointers. In other words, they are pointers that appear whenever the pointer's hot spot is not over graphical objects that are either legal or illegal destinations for the drop.

These pointer shapes appear while the pointer is over the workspace, over the backgrounds of windows or control areas, or over objects that don't subscribe to the drag and drop protocol.¹

When the pointer's hot spot is over a text data pane or a text field, its image changes to one of the text insert drop allowed pointers shown in Figure A-10. Specifically, the arrow changes to look like a cross-hair. To facilitate the accurate insertion of the data being dragged into the existing text, the interior

---

1. These pointers are also used over graphical objects that do subscribe to the protocol, but for some reason cannot provide feedback about whether a drop is allowed.

of the cross-hair itself must be transparent. Ideally, the cross-hair pointer should be used only when the pointer is over a drop site whose semantics call for insertion of the data being dragged into the data at the drop site. Note that the change to the text insert drop allowed pointer should take place immediately when dragging a text selection in a data pane (unless it is read only), since the text can be dropped anywhere within the same pane.

Figure A-10

When the pointer is over a drag and drop target (or any other drop site where the drop semantics indicate a replacement of the current data), the pointer should change to one of the text replace drop allowed images shown in Figure A-11. Specifically, the arrow in the pointer should change to a bull's-eye that is the same as the drop allowed feedback used elsewhere. If an implementation is unable to support different pointer images over explicit drag and drop targets and implicit drop sites (data panes or individual controls), then the text insert drop allowed (cross-hair) pointer should be used to provide drop allowed feedback over all legal drop sites (including drag and drop targets) while the text is being dragged.

Figure A-11

When the pointer is over a graphical object that cannot accept the text selection as a drop, the pointer changes to one of the text drop not allowed pointers. See Figure A-12. Specifically, the arrow changes to look like the drop not allowed symbol shown in Figure A-8 on page A-23.

Figure A-12

While Dragging Selected Data other than Text

When dragging a selection containing non-text data that does not itself represent an object or a container, the pointer changes to the selection move or selection copy pointer, depending on whether you are holding down the Duplicate key. See Figure A-13. These pointers are analogous to the text move and text copy pointers shown in Figure A-9 on page A-24, but they do not include any "preview" of the data being dragged (that is, there is no indication of the actual contents of the selection). The source application may choose to include an optional glyph within the rectangular area of the pointer to indicate the type of data being dragged (see Figure A-13 on page A-27) but, by default, the rectangle is empty.

As in the case of text selections, the implementation should allow for the use of both selection insert drop allowed and selection replace drop allowed pointers (see Figure A-13) when it can make the appropriate distinctions between drop sites with insert semantics and those with replace semantics. If the implementation cannot support different pointer images over drag and drop targets and implicit drop sites (data panes or individual controls), then the selection insert drop allowed (cross-hair) pointer should be used to provide drop allowed feedback over all legal drop sites (including drag and drop targets).

When dragging selections in data panes containing sequential data types (that is, types such as audio that are characterized by a one-dimensional array in which new data displaces existing data at a specific insert point), the pointer image should change immediately to the selection insert drop allowed pointer, since an insert point must be specified even in the source data pane.

When dragging selections within data panes containing non-sequential data types (that is, types such as structured graphics, in which data can be moved to arbitrary spatial locations and can overlap any data that is already displayed in those locations), the pointer image should change immediately to the move or copy pointer, but should not display the drop allowed or drop not allowed symbol while over the original data pane, since any point in the source data pane constitutes a legal drop site. In addition to changing the pointer's shape, the source application should attach a graphical image - as similar as possible to the size and shape of the actual selected data - that provides a WYSIWYG preview of the effect of a drop. If the pointer and image being dragged are moved out of the source data pane, the appropriate selection drop allowed pointer should be displayed whenever the hot spot is over any legal drop site, including other compatible data panes or the original source data pane.

When the pointer is over a graphical object that cannot accept the data being dragged, the pointer image changes to one of the selection drop not allowed pointers. See Figure A-13. As in the case of text drags, the arrow changes to look like the drop not allowed symbol shown in Figure A-8 on page A-23.

Figure A-13

A.10.2 During the Drop

The destination assumes a busy appearance while processing a drop. Once the operation is complete, the destination resumes its normal appearance. If the application can process the drop in the time it would take to post and clear the busy appearance change, then the application may choose not to post the busy appearance.

A.11 Input Focus Management

When you drag an object between windows, the input focus moves to the destination window. Within the destination window, the input focus moves to the element the object was dropped on, assuming it is an element that ordinarily receives the input focus. For example, if you drop a text selection into a text pane, the text pane receives the input focus. If the destination element cannot receive the input focus (as, for example, drag and drop targets can't), the input focus goes to the element in the window that ordinarily receives it when the window receives the input focus.

When you drag an object from one location to another within the same window, the input focus moves to the destination element, assuming it is capable of receiving the input focus. If the destination element cannot receive the input focus, the input focus remains at the source location.

A.12 Error Handling

The best user interfaces are designed for error, and drag and drop is no exception. Errors inevitably occur as a result of user mistakes and as a result of system errors. Drag operations may fail for any of the following reasons:

• The user dropped the source object over a destination that does not subscribe to the drag and drop protocol.
• The source object is of a type the destination cannot accept.

  Although the visual feedback on the pointer is designed to minimize this sort of problem, the feedback is not infallible. And, of course, we can't count on users' actions conforming to the recommendations of the feedback, in any case.

• For some reason the drop operation was aborted.

A drop might be aborted either because of a failure of the transport mechanism used by drag and drop; or because of complications the destination application encounters while processing the drop (such as running out of space in the file system); or for other reasons.

When a drag operation fails, either, but not both, the source application or the destination application presents a Notice window telling the user what has happened. During the drag before the source application has established communication with the destination, the source is responsible for all Notice windows. After communication with the destination has been established, the destination assumes responsibility for Notice windows. The application that does not present the Notice window may choose to display an error message in its base window footer.

In cases of intra-application drags, the application may present a message in a window footer rather than in a Notice window. In either case, the message should explain why the drop failed, and provide constructive guidance to the user about how to avoid failure in the future (if possible).

A.13 Undoing the Effects of Drag and Drop

You can undo the effects of a drag operation by using an Undo menu item or command button, or the Undo function key, in both the source and destination applications (assuming the operation is undo-able).¹ An Undo action in the source application undoes the effect of the drag operation on the source; whereas an Undo action in the destination application undoes the effect there.

A.14 Canceling a Drag Operation in Progress

If you decide to cancel a drag operation while you still have the mouse button held down, you can press the STOP key and then release the mouse button.

---

1. The Undo function key operates on the window with the keyboard input focus.

1 A.15 Deviations from the OPEN LOOK Style Guidelines

For the most part, the guidelines in this document extend the guidelines in the OPEN LOOK Application Style Guidelines. However, a few of the guidelines described in this document differ from those of the style guide. Applications designed to run on the OpenWindows Environment should follow the guidelines described here rather than those in the style guide.

A summary of the discrepancies follows:

• Differences between unmodified-drag and Duplicate-drag

  According to the style guide, whenever a user initiates a drag operation without holding down the Duplicate key (i.e., Ctrl), the drag operation should be interpreted as a request to relocate the source object. In other words, unmodified-drags should always be interpreted as requests to move the source object from its original location to the destination. In cases where such actions would result in unexpected loss of data, the destination application may refuse to receive data transferred by unmodified-drag operations. The destination application should present a Notice window to allow users either to cancel the drag operation or to change it to a duplicate operation.

  The guidelines described in this document allow applications to interpret unmodified-drag operations as identical to Duplicate-drag operations to prevent unanticipated loss of data.

  Refer to OPEN LOOK Application Style Guidelines page 165 and to "To Copy or Not to Copy?" on page A-17 in this document.

• Dropping one mini-window onto another

  The style guide recommends that applications allow users to drop mini-windows onto one another, which should transfer or copy data from the source application to the destination application.

---

1. Sun Microsystems, Inc. (1990) OPEN LOOK Graphical User Interface Application Style Guidelines. Reading, MA: Addison-Wesley Publishing Company, Inc.

This document states that when one mini-window is dropped onto another it is as if they are resting on top of one another on the workspace. That is, when you drop one mini-window onto another, the destination application is not the overlaid mini-window, it is the application that owns the workspace (i.e., the window manager).

Refer to the OPEN LOOK Application Style Guidelines and to "The Source" on page A-6 of this document.

• Dropping objects onto window backgrounds

  The style guide says that a user may drop a source object onto the background of a base window, resulting in loading the source into the window (replacing the previous content).

  This document specifies that applications should use drag and drop targets in their control areas for this purpose. If an application doesn't have a control area, and, consequently, doesn't have a place to put a drag and drop target, it may allow drops onto its window header.¹

  Refer to page 164 in the style guide and to the section called "Drag and Drop Targets" on page A-13 of this document.

A.16 Drag and Drop Target Engineering Specification

Two standard sizes are defined for the drag and drop target. The smaller size (see Figure A-14 on page A-32) is used in the control area above an OPEN LOOK base window when that control area contains only one row of buttons. The larger standard size (see Figure A-15 on page A-33) is designed to display a standard File Manager document glyph within its borders. Its dimensions are the same for all scaling factors because the same set of File Manager glyphs is used in all cases.

Applications can specify the position of the drag and drop target as well as its width and height. The standard "3D" border must always be used, since this is the only aspect of the target itself that directly identifies the drag and drop target as an explicit drop site.

---

1. Applications that convert from the old policy to the new one should provide constructive guidance in error messages to help users with the transition. Specifically, if a user drops onto the window background, the application should present an explanatory error message that describes that the drag and drop target (or window header) should be used in place of the window background.

Figure A-14

Table A-2

	10 pt	12 pt	14 pt	19 pt
(a)	19.0	21.0	23.0	30.0
(b)	14.0	15.5	17.0	22.0
(c)	2.6	3.0	3.4	4.4
(d	0.8	1.0	1.2	1.6

Figure A-15

Table A-3

All
(a)50 (b)45 (c)6 (d)1