Browse Prior Art Database

Direct Manipulation Multi-Tasking Window Search Mechanism

IP.com Disclosure Number: IPCOM000105653D
Original Publication Date: 1993-Aug-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 2 page(s) / 88K

Publishing Venue

IBM

Related People

Hindocha, N: AUTHOR [+3]

Abstract

A feature which is becoming increasingly standard in graphical applications is direct manipulation, or drag-and-drop. This provides the user the ability to click with the mouse button when the pointer is over an object, move the mouse elsewhere and release the button. The object is then moved or copied from one location to another, or an application is invoked with the objects as data, or another effect is defined by the two applications.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Direct Manipulation Multi-Tasking Window Search Mechanism

      A feature which is becoming increasingly standard in graphical
applications is direct manipulation, or drag-and-drop.  This provides
the user the ability to click with the mouse button when the pointer
is over an object, move the mouse elsewhere and release the button.
The object is then moved or copied from one location to another, or
an application is invoked with the objects as data, or another effect
is defined by the two applications.

      For efficiency and maintainability, it is desirable that the
application programmer has access to a programming interface (API)
that is as consistent as possible across all the target platforms.
Thus instead of learning all the details of systems that support
direct manipulation, the programmer writes to a single API which is
translated by a building tool into the native environment.  This
disclosure describes a mechanism and programming interface necessary
to generalize direct manipulation and enable the programmer to write
platform-independent (rather than platform-specific) code for direct
manipulation.  Specifically, the AIXwindows* desktop, XDT, does not
surface to the desktop programmer the window from which an object
being dropped (a dropin) came, since no notification protocol is
defined.  However, this information is required since an application
that drops onto the desktop will generally wish to know the result of
the dropin.  For example, in the case of dropping a file onto the
desktop trashcan (only files may be dropped onto the desktop), the
application wishes to know that the file has been deleted.  Therefore
DMS on AIXwindows enables a notification program invoked by the
desktop to find where a dropin came from.

      To achieve this, a property is written to the root window every
time a dropin is performed to the desktop.  This property contains
the names of the files dropped, and the name of the property itself
contains the ID of the sending window encoded into it.  Thus a
notification program may search the root window for properties of the
right type containing the files dropped and extract the sending
window from the property name.  Once this window has been found the
notification may be sent to it in the normal manner.

      This mechanism, or a similar one, may well be required to
support other applications, on this and other systems, that only
define a one-way protocol.  An example implementation is shown and
described below:

     DMS_Status DMS_NotifyAction (rwindow, swindow, dro...