Drag and Drop

Drag and drop is a feature of the BeOS that lets users move objects and data within and between applications. A user performs a drag and drop operation by mousing-down on a draggable object, dragging it to a view that will accept it, and dropping it there. We're all used to this feature when applied to files: Dragging and dropping a file into a folder moves (or copies) the file into the folder. But drag and drop has other uses as well:

To play the drag and drop game, your application can be a draggable object provider, a draggable object consumer, or both. Beyond the programming mechanics of the thing, you also have to provide some visual feedback to let the user know...

This chapter gives guidelines for relaying these states to the user. These suggestions apply to non-text data only: For dragging and dropping text, for which the guidelines are a bit stricter, see 28266: chTitle: Working with Text.


1.0.0 Terms


2.0.0 The Drag

The following sections describe what happens before and during a drag.


2.1.0 Indicating a Drag Object

When a user moves the cursor over a drag object, your application should provide some sort of feedback to indicate that the object can be dragged.

The preferred method is to change the cursor to the (default) pointing hand when the mouse is poised over a drag object. However, if your app is already displaying the pointing hand cursor (such that a change to the hand would not be seen), you should change the cursor to a custom image.

Alternatively (or additionally), you can highlight or outline the drag object. Outlining is good if the object has a distinct silhouette, but you shouldn't use it if the object is an entire rectangular view, since highlighting the boundaries of a view is the preferred method for indicating a target view (as explained below).


2.2.0 Representing the Drag Object during a Drag

Your application should display some representation of the drag object as it's being dragged.

If applicable, you should show the data itself. For example, if the user drags an image, the image itself should follow the mouse. If the selected data is too big, or if it doesn't make sense to (literally) show the data, you should display an image or icon that depicts the type of data that's being dragged.

If you display an image, you should make the image transparent (if possible) so that it doesn't obscure the target.

If you want to be lazy, just show an outline of the selection. The API provides direct support for representing a drag object as a rectangular outline.

Regardless of the method you choose, the dragged representation is static:

Once the drag has started, there's no way to change, update, or animate the representation of the drag object.


2.3.0 Indicating a Target View

When a user drags an object over a view that's capable of accepting the object, the view should provide some sort of visual feedback.

A simple but effective indicator is to highlight the boundaries of the target view. Alternatively—or in addition to the highlight— you may want to display a custom cursor.

If applicable, the target view should provide some indication of where the drop location will actually be. A text view, for example, should move the insertion point as the object is dragged around the view. If the drop location is within a selection, the entire selection should be outlined or otherwise highlighted.

2.3.1 Functional Feedback

If the drag object is a function, you should preview the effect of the function on the target view's data (time permitting) as the object is dragged over the target.

You can preview the effect by changing the data in-place, or by displaying a "preview panel." If you change the data in-place, be prepared to restore the original data if the user doesn't actually drop the object.

2.3.2 Negative Feedback

You should only provide "positive target feedback" if the drag object's data is a type that the target view will accept.

If the target isn't buying what the drag object has to offer, it should either do nothing or display "negative target feedback". The preferred negative feedback is to draw the view so it looks disabled.


3.0.0 The Drop

When a drag object is dropped, the target view must first make sure that it can accept the data:

If the target view doesn't accept the object, it should do nothing.

The target doesn't have to explain that the data isn't being accepted, or try to send the data back to the source.


3.1.0 Accepting Data

If the object contains data, the target should make sure it accepts that type of data, and then copy or move the data into itself:

If the target view is the same as the source view, the data is moved. If the target and source are different, the data is copied.

If the user is holding down the Option key, the data is copied (even if the source and target are the same view).

If the target is displaying a selection and the drop location is within that selection, the selection is replaced with the contents of the dropped object.


3.2.0 Accepting a Function

If the drag object represents a function, the target applies the function to itself. The scope and range of the affected data is determined by the target (and the nature of the function). However...

If the target view is displaying a selection and the drop location is within that selection, the function is applied to the selection only.


3.3.0 The Target View's Window

When a drag object is dropped, the target view's window should not be made active. If the window is already active, don't deactivate it.





The Be Book,
...in lovely HTML...
for BeOS Genki.

Copyright © 1999 Be, Inc. All rights reserved.

Text last modified April 21, 1999.