Drag-n-Drop Interface Changes

Owner: ???

Effort: ???

Dependencies: Lisp Interface Changes

Abstract: I propose completely redoing the drag-n-drop interface to make it powerful and extensible enough to support such concepts as drag over and drag under visuals and context menus invoked when a drag is done with the right mouse button, to allow drop handlers to be defined for all sorts of graphical elements including buffers, extents, mode lines, toolbar items, menubar items, glyphs, etc., and to allow different packages to add and remove drop handlers for the same drop sites without interfering with each other. The changes are extensive enough that I think they can only be implemented in version 22, and the drag-n-drop interface should remain experimental until then.

The new drag-n-drop interface centers around the twin concepts of drop site and drop handler. A drop site specifies a particular graphical element where an object can be dropped onto, and a drop handler encapsulates all of the behavior that happens when such an object is dragged over and dropped onto a drop site.

Each drop site has an object associated with it which is passed to functions that are part of the drop handlers associated with that site. The type of this object depends on the graphical element that comprises the drop site. The drop site object can be a buffer, an extent, a glyph, a menu path, a toolbar item path, etc. (These last two object types are defined in Lisp Interface Changes in the sections on menu and toolbar API changes. If we wanted to allow drops onto other kinds of drop sites, for example mode lines, we would have to create corresponding path objects). Each such object type should be able to be accessed using the generalized property interface defined above, and should have a property called drop-handlers associated with it that specifies all of the drop handlers associated with the drop site. Normally, this property is not accessed directly, but instead by using the drop handler API defined below, and Lisp packages should not make any assumptions about the format of the data contained in the drop-handlers property.

Each drop handler has an object of type drop-handler associated with it, whose primary purpose is to be a container for the various properties associated with a particular drop handler. These could include, for example, a function invoked when the drop occurs, a context menu invoked when a drop occurs as a result of a drag with the right mouse button, functions invoked when a dragged object enters, leaves, or moves within a drop site, the shape that the mouse pointer changes to when an object is dragged over a drop site that allows this particular object to be dropped onto it, the MIME types (actually a regular expression matching the MIME types) of the allowable objects that can be dropped onto the drop site, a package tag (a symbol specifying the package that created the drop handler, used for identification purposes), etc. The drop handler object is passed to the functions that are invoked as a result of a drag or a drop, most likely indirectly as one of the properties of the drag or drop event passed to the function. Properties of a drop handler object are accessed and modified in the standard fashion using the generalized property interface.

A drop handler is added to a drop site using the add-drop-handler function. The drop handler itself can either be created separately using the make-drop-handler function and then passed in as one of the parameters to add-drop-handler, or it will be created automatically by the add-drop-handler function, if the drop handler argument is omitted, but keyword arguments corresponding to the valid keyword properties for a drop handler are specified in the add-drop-handler call. Other functions, such as find-drop-handler, add-drop-handler (when specifying a drop handler before which the drop handler in question is to be added), remove-drop-handler etc. should be defined with obvious semantics. All of these functions take or return a drop site object which, as mentioned above, can be one of several object types corresponding to graphical elements. Defined drop handler functions locate a particular drop handler using either the MIME-type or package-tag property of the drop handler, as defined above.

Logically, the drop handlers associated with a particular drop site are an ordered list. The first drop handler whose specified MIME type matches the MIME type of the object being dragged or dropped controls what happens to this object. This is important particularly because the specified MIME type of the drop handler can be a regular expression that, for example, matches all audio objects with any sub-type.

In the current drag-n-drop API, there is a distinction made between objects with an associated MIME type and objects with an associated URL. I think that this distinction is arbitrary, and should not exist. All objects should have a MIME type associated with them, and a new XEmacs-specific MIME type should be defined for URLs, file names, etc. as necessary. I am not even sure that this is necessary, however, as the MIME specification may specify a general concept of a pointer or link to an object, which is exactly what we want. Also in some cases (for example, the name of a file that is locally available), the pointer or link will have another MIME type associated with it, which is the type of the object that is being pointed to. I am not quite sure how we should handle URL and file name objects being dragged, but I am positive that it needs to be integrated with the mechanism used when an object itself is being dragged or dropped.

As is described in a separate page, the misc-user-event event type should be removed and split up into a number of separate event types. Two such event types would be drag-event and drop-event. A drop event is used when an object is actually dropped, and a drag event is used if a function is invoked as part of the dragging process. (Such a function would typically be used to control what are called drag under visuals, which are changes to the appearance of the drop site reflecting the fact that a compatible object is being dragged over it). The drag events and drop events encapsulate all of the information that is pertinent to the drag or drop action occurring, including such information as the actual MIME type of the object in question, the drop handler that caused a function to be invoked, the mouse event (or possibly even a keyboard event) corresponding to the user's action that is causing the drag or drop, etc. This event is always passed to any function that is invoked as a result of the drag or drop. There should never be any need to refer to the current-mouse-event variable, and in fact, this variable should not be changed at all during a drag or a drop.

Ben Wing

Conform with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Automatically validated by PSGML