view man/lispref/dragndrop.texi @ 939:025200a2163c

[xemacs-hg @ 2002-07-31 07:23:39 by michaels] 2002-07-17 Marcus Crestani <crestani@informatik.uni-tuebingen.de> Markus Kaltenbach <makalten@informatik.uni-tuebingen.de> Mike Sperber <mike@xemacs.org> configure flag to turn these changes on: --use-kkcc First we added a dumpable flag to lrecord_implementation. It shows, if the object is dumpable and should be processed by the dumper. * lrecord.h (struct lrecord_implementation): added dumpable flag (MAKE_LRECORD_IMPLEMENTATION): fitted the different makro definitions to the new lrecord_implementation and their calls. Then we changed mark_object, that it no longer needs a mark method for those types that have pdump descritions. * alloc.c: (mark_object): If the object has a description, the new mark algorithm is called, and the object is marked according to its description. Otherwise it uses the mark method like before. These procedures mark objects according to their descriptions. They are modeled on the corresponding pdumper procedures. (mark_with_description): (get_indirect_count): (structure_size): (mark_struct_contents): These procedures still call mark_object, this is needed while there are Lisp_Objects without descriptions left. We added pdump descriptions for many Lisp_Objects: * extents.c: extent_auxiliary_description * database.c: database_description * gui.c: gui_item_description * scrollbar.c: scrollbar_instance_description * toolbar.c: toolbar_button_description * event-stream.c: command_builder_description * mule-charset.c: charset_description * device-msw.c: devmode_description * dialog-msw.c: mswindows_dialog_id_description * eldap.c: ldap_description * postgresql.c: pgconn_description pgresult_description * tooltalk.c: tooltalk_message_description tooltalk_pattern_description * ui-gtk.c: emacs_ffi_description emacs_gtk_object_description * events.c: * events.h: * event-stream.c: * event-Xt.c: * event-gtk.c: * event-tty.c: To write a pdump description for Lisp_Event, we converted every struct in the union event to a Lisp_Object. So we created nine new Lisp_Objects: Lisp_Key_Data, Lisp_Button_Data, Lisp_Motion_Data, Lisp_Process_Data, Lisp_Timeout_Data, Lisp_Eval_Data, Lisp_Misc_User_Data, Lisp_Magic_Data, Lisp_Magic_Eval_Data. We also wrote makro selectors and mutators for the fields of the new designed Lisp_Event and added everywhere these new abstractions. We implemented XD_UNION support in (mark_with_description), so we can describe exspecially console/device specific data with XD_UNION. To describe with XD_UNION, we added a field to these objects, which holds the variant type of the object. This field is initialized in the appendant constructor. The variant is an integer, it has also to be described in an description, if XD_UNION is used. XD_UNION is used in following descriptions: * console.c: console_description (get_console_variant): returns the variant (create_console): added variant initialization * console.h (console_variant): the different console types * console-impl.h (struct console): added enum console_variant contype * device.c: device_description (Fmake_device): added variant initialization * device-impl.h (struct device): added enum console_variant devtype * objects.c: image_instance_description font_instance_description (Fmake_color_instance): added variant initialization (Fmake_font_instance): added variant initialization * objects-impl.h (struct Lisp_Color_Instance): added color_instance_type * objects-impl.h (struct Lisp_Font_Instance): added font_instance_type * process.c: process_description (make_process_internal): added variant initialization * process.h (process_variant): the different process types
author michaels
date Wed, 31 Jul 2002 07:23:39 +0000
parents 47c30044fc4e
children bc4f2511bbea
line wrap: on
line source

@c -*-texinfo-*-
@c This is part of the XEmacs Lisp Reference Manual.
@c Copyright (C) 1998 Oliver Graf <ograf@fga.de>
@c Original reference is (c) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc.
@c See the file lispref.texi for copying conditions.
@setfilename ../../info/dragndrop.texi
@node Drag and Drop, Modes, Scrollbars, Top
@chapter Drag and Drop
@cindex drag and drop

@emph{WARNING}: the Drag'n'Drop API is still under development and the
interface may change! The current implementation is considered experimental.

  Drag'n'drop is a way to transfer information between multiple applications.
To do this several GUIs define their own protocols. Examples are OffiX, CDE,
Motif, KDE, MSWindows, GNOME, and many more. To catch all these protocols,
XEmacs provides a generic API.

One prime idea behind the API is to use a data interface that is
transparent for all systems. The author thinks that this is best
archived by using URL and MIME data, cause any internet enabled system
must support these for email already. XEmacs also already provides
powerful interfaces to support these types of data (tm and w3).

@menu
* Supported Protocols:: Which low-level protocols are supported.
* Drop Interface::      How XEmacs handles a drop from another application.
* Drag Interface::      Calls to initiate a drag from XEmacs.
@end menu

@node Supported Protocols
@section Supported Protocols

The current release of XEmacs only support a small set of Drag'n'drop
protocols. Some of these only support limited options available in the API.

@menu
* OffiX DND::           A generic X based protocol.
* CDE dt::              Common Desktop Environment used on suns.
* MSWindows OLE::       Mr. Gates way of live.
* Loose ends::          The other protocols.
@end menu

@node OffiX DND
@subsection OffiX DND
@cindex OffiX DND

@emph{WARNING}: If you compile in OffiX, you may not be able to use
multiple X displays successfully.  If the two servers are from
different vendors, the results may be unpredictable.

The OffiX Drag'n'Drop protocol is part of a X API/Widget library created by
Cesar Crusius. It is based on X-Atoms and ClientMessage events, and works with
any X platform supporting them.

OffiX is supported if 'offix is member of the variable dragdrop-protocols, or
the feature 'offix is defined.

Unfortunately it uses it's own data types. Examples are: File, Files,
Exe, Link, URL, MIME. The API tries to choose the right type for the data that
is dragged from XEmacs (well, not yet...).

XEmacs supports both MIME and URL drags and drops using this API. No application
interaction is possible while dragging is in progress.

For information about the OffiX project have a look at http://leb.net/~offix/

@node CDE dt
@subsection CDE dt
@cindex CDE dt

CDE stands for Common Desktop Environment. It is based on the Motif
widget library. It's drag'n'drop protocol is also an abstraction of the
Motif protocol (so it might be possible, that XEmacs will also support
the Motif protocol soon).

CDE has three different types: file, buffer, and text. XEmacs only uses
file and buffer drags. The API will disallow full URL drags, only file
method URLs are passed through.

Buffer drags are always converted to plain text.

@node MSWindows OLE
@subsection MSWindows OLE
@cindex MSWindows OLE

Only allows file drags and drops.

@node Loose ends
@subsection Loose ends

The following protocols will be supported soon: Xdnd, Motif, Xde (if I
get some specs), KDE OffiX (if KDE can find XEmacs windows).

In particular Xdnd will be one of the protocols that can benefit from
the XEmacs API, cause it also uses MIME types to encode dragged data.

@node Drop Interface
@section Drop Interface
@cindex drop
@cindex Drop API

For each activated low-level protocol, an internal routine will catch
incoming drops and convert them to a dragdrop-drop type
misc-user-event.

This misc-user-event has its function argument set to
@code{dragdrop-drop-dispatch} and the object contains the data of the drop
(converted to URL/MIME specific data). This function will search the variable
@code{experimental-dragdrop-drop-functions} for a function that can handle the
dropped data.

To modify the drop behavior, the user can modify the variable
@code{experimental-dragdrop-drop-functions}. Each element of this list
specifies a possible handler for dropped data. The first one that can handle
the data will return @code{t} and exit. Another possibility is to set a
extent-property with the same name. Extents are checked prior to the
variable.

The customization group @code{drag-n-drop} shows all variables of user
interest.

@node Drag Interface
@section Drag Interface
@cindex drag
@cindex Drag API

This describes the drag API (not implemented yet).