1 | /****************************************************************************
|
---|
2 | **
|
---|
3 | ** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
|
---|
4 | ** All rights reserved.
|
---|
5 | ** Contact: Nokia Corporation ([email protected])
|
---|
6 | **
|
---|
7 | ** This file is part of the documentation of the Qt Toolkit.
|
---|
8 | **
|
---|
9 | ** $QT_BEGIN_LICENSE:LGPL$
|
---|
10 | ** Commercial Usage
|
---|
11 | ** Licensees holding valid Qt Commercial licenses may use this file in
|
---|
12 | ** accordance with the Qt Commercial License Agreement provided with the
|
---|
13 | ** Software or, alternatively, in accordance with the terms contained in
|
---|
14 | ** a written agreement between you and Nokia.
|
---|
15 | **
|
---|
16 | ** GNU Lesser General Public License Usage
|
---|
17 | ** Alternatively, this file may be used under the terms of the GNU Lesser
|
---|
18 | ** General Public License version 2.1 as published by the Free Software
|
---|
19 | ** Foundation and appearing in the file LICENSE.LGPL included in the
|
---|
20 | ** packaging of this file. Please review the following information to
|
---|
21 | ** ensure the GNU Lesser General Public License version 2.1 requirements
|
---|
22 | ** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
|
---|
23 | **
|
---|
24 | ** In addition, as a special exception, Nokia gives you certain additional
|
---|
25 | ** rights. These rights are described in the Nokia Qt LGPL Exception
|
---|
26 | ** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
|
---|
27 | **
|
---|
28 | ** GNU General Public License Usage
|
---|
29 | ** Alternatively, this file may be used under the terms of the GNU
|
---|
30 | ** General Public License version 3.0 as published by the Free Software
|
---|
31 | ** Foundation and appearing in the file LICENSE.GPL included in the
|
---|
32 | ** packaging of this file. Please review the following information to
|
---|
33 | ** ensure the GNU General Public License version 3.0 requirements will be
|
---|
34 | ** met: http://www.gnu.org/copyleft/gpl.html.
|
---|
35 | **
|
---|
36 | ** If you have questions regarding the use of this file, please contact
|
---|
37 | ** Nokia at [email protected].
|
---|
38 | ** $QT_END_LICENSE$
|
---|
39 | **
|
---|
40 | ****************************************************************************/
|
---|
41 |
|
---|
42 | /*!
|
---|
43 | \group draganddrop
|
---|
44 | \title Drag And Drop Classes
|
---|
45 |
|
---|
46 | \brief Classes dealing with drag and drop and mime type encoding and decoding.
|
---|
47 | */
|
---|
48 |
|
---|
49 | /*!
|
---|
50 | \page dnd.html
|
---|
51 | \title Drag and Drop
|
---|
52 | \brief An overview of the drag and drop system provided by Qt.
|
---|
53 |
|
---|
54 | \ingroup frameworks-technologies
|
---|
55 |
|
---|
56 | Drag and drop provides a simple visual mechanism which users can use
|
---|
57 | to transfer information between and within applications. (In the
|
---|
58 | literature this is referred to as a "direct manipulation model".) Drag
|
---|
59 | and drop is similar in function to the clipboard's cut and paste
|
---|
60 | mechanism.
|
---|
61 |
|
---|
62 | \tableofcontents
|
---|
63 |
|
---|
64 | This document describes the basic drag and drop mechanism and
|
---|
65 | outlines the approach used to enable it in custom widgets. Drag
|
---|
66 | and drop operations are also supported by Qt's item views and by
|
---|
67 | the graphics view framework; more information is available in the
|
---|
68 | \l{Using Drag and Drop with Item Views} and \l{The Graphics View
|
---|
69 | Framework} documents.
|
---|
70 |
|
---|
71 | \section1 Drag and Drop Classes
|
---|
72 |
|
---|
73 | These classes deal with drag and drop and the necessary mime type
|
---|
74 | encoding and decoding.
|
---|
75 |
|
---|
76 | \annotatedlist draganddrop
|
---|
77 |
|
---|
78 | \section1 Configuration
|
---|
79 |
|
---|
80 | The QApplication object provides some properties that are related
|
---|
81 | to drag and drop operations:
|
---|
82 |
|
---|
83 | \list
|
---|
84 | \i \l{QApplication::startDragTime} describes the amount of time in
|
---|
85 | milliseconds that the user must hold down a mouse button over an
|
---|
86 | object before a drag will begin.
|
---|
87 | \i \l{QApplication::startDragDistance} indicates how far the user has to
|
---|
88 | move the mouse while holding down a mouse button before the movement
|
---|
89 | will be interpreted as dragging. Use of high values for this quantity
|
---|
90 | prevents accidental dragging when the user only meant to click on an
|
---|
91 | object.
|
---|
92 | \endlist
|
---|
93 |
|
---|
94 | These quantities provide sensible default values for you to use if you
|
---|
95 | provide drag and drop support in your widgets.
|
---|
96 |
|
---|
97 | \section1 Dragging
|
---|
98 |
|
---|
99 | To start a drag, create a QDrag object, and call its
|
---|
100 | exec() function. In most applications, it is a good idea to begin a drag
|
---|
101 | and drop operation only after a mouse button has been pressed and the
|
---|
102 | cursor has been moved a certain distance. However, the simplest way to
|
---|
103 | enable dragging from a widget is to reimplement the widget's
|
---|
104 | \l{QWidget::mousePressEvent()}{mousePressEvent()} and start a drag
|
---|
105 | and drop operation:
|
---|
106 |
|
---|
107 | \snippet doc/src/snippets/dragging/mainwindow.cpp 0
|
---|
108 | \dots 8
|
---|
109 | \snippet doc/src/snippets/dragging/mainwindow.cpp 2
|
---|
110 |
|
---|
111 | Although the user may take some time to complete the dragging operation,
|
---|
112 | as far as the application is concerned the exec() function is a blocking
|
---|
113 | function that returns with \l{Qt::DropActions}{one of several values}.
|
---|
114 | These indicate how the operation ended, and are described in more detail
|
---|
115 | below.
|
---|
116 |
|
---|
117 | Note that the exec() function does not block the main event loop.
|
---|
118 |
|
---|
119 | For widgets that need to distinguish between mouse clicks and drags, it
|
---|
120 | is useful to reimplement the widget's
|
---|
121 | \l{QWidget::mousePressEvent()}{mousePressEvent()} function to record to
|
---|
122 | start position of the drag:
|
---|
123 |
|
---|
124 | \snippet doc/src/snippets/draganddrop/dragwidget.cpp 6
|
---|
125 |
|
---|
126 | Later, in \l{QWidget::mouseMoveEvent()}{mouseMoveEvent()}, we can determine
|
---|
127 | whether a drag should begin, and construct a drag object to handle the
|
---|
128 | operation:
|
---|
129 |
|
---|
130 | \snippet doc/src/snippets/draganddrop/dragwidget.cpp 7
|
---|
131 | \dots
|
---|
132 | \snippet doc/src/snippets/draganddrop/dragwidget.cpp 8
|
---|
133 |
|
---|
134 | This particular approach uses the \l QPoint::manhattanLength() function
|
---|
135 | to get a rough estimate of the distance between where the mouse click
|
---|
136 | occurred and the current cursor position. This function trades accuracy
|
---|
137 | for speed, and is usually suitable for this purpose.
|
---|
138 |
|
---|
139 | \section1 Dropping
|
---|
140 |
|
---|
141 | To be able to receive media dropped on a widget, call
|
---|
142 | \l{QWidget::setAcceptDrops()}{setAcceptDrops(true)} for the widget,
|
---|
143 | and reimplement the \l{QWidget::dragEnterEvent()}{dragEnterEvent()} and
|
---|
144 | \l{QWidget::dropEvent()}{dropEvent()} event handler functions.
|
---|
145 |
|
---|
146 | For example, the following code enables drop events in the constructor of
|
---|
147 | a QWidget subclass, making it possible to usefully implement drop event
|
---|
148 | handlers:
|
---|
149 |
|
---|
150 | \snippet doc/src/snippets/dropevents/window.cpp 0
|
---|
151 | \dots
|
---|
152 | \snippet doc/src/snippets/dropevents/window.cpp 1
|
---|
153 | \snippet doc/src/snippets/dropevents/window.cpp 2
|
---|
154 |
|
---|
155 | The dragEnterEvent() function is typically used to inform Qt about the
|
---|
156 | types of data that the widget accepts.
|
---|
157 | You must reimplement this function if you want to receive either
|
---|
158 | QDragMoveEvent or QDropEvent in your reimplementations of
|
---|
159 | \l{QWidget::dragMoveEvent()}{dragMoveEvent()} and
|
---|
160 | \l{QWidget::dropEvent()}{dropEvent()}.
|
---|
161 |
|
---|
162 | The following code shows how \l{QWidget::dragEnterEvent()}{dragEnterEvent()}
|
---|
163 | can be reimplemented to
|
---|
164 | tell the drag and drop system that we can only handle plain text:
|
---|
165 |
|
---|
166 | \snippet doc/src/snippets/dropevents/window.cpp 3
|
---|
167 |
|
---|
168 | The \l{QWidget::dropEvent()}{dropEvent()} is used to unpack dropped data
|
---|
169 | and handle it in way that is suitable for your application.
|
---|
170 |
|
---|
171 | In the following code, the text supplied in the event is passed to a
|
---|
172 | QTextBrowser and a QComboBox is filled with the list of MIME types that
|
---|
173 | are used to describe the data:
|
---|
174 |
|
---|
175 | \snippet doc/src/snippets/dropevents/window.cpp 4
|
---|
176 |
|
---|
177 | In this case, we accept the proposed action without checking what it is.
|
---|
178 | In a real world application, it may be necessary to return from the
|
---|
179 | \l{QWidget::dropEvent()}{dropEvent()} function without accepting the
|
---|
180 | proposed action or handling
|
---|
181 | the data if the action is not relevant. For example, we may choose to
|
---|
182 | ignore Qt::LinkAction actions if we do not support
|
---|
183 | links to external sources in our application.
|
---|
184 |
|
---|
185 | \section2 Overriding Proposed Actions
|
---|
186 |
|
---|
187 | We may also ignore the proposed action, and perform some other action on
|
---|
188 | the data. To do this, we would call the event object's
|
---|
189 | \l{QDropEvent::setDropAction()}{setDropAction()} with the preferred
|
---|
190 | action from Qt::DropAction before calling \l{QEvent::}{accept()}.
|
---|
191 | This ensures that the replacement drop action is used instead of the
|
---|
192 | proposed action.
|
---|
193 |
|
---|
194 | For more sophisticated applications, reimplementing
|
---|
195 | \l{QWidget::dragMoveEvent()}{dragMoveEvent()} and
|
---|
196 | \l{QWidget::dragLeaveEvent()}{dragLeaveEvent()} will let you make
|
---|
197 | certain parts of your widgets sensitive to drop events, and give you more
|
---|
198 | control over drag and drop in your application.
|
---|
199 |
|
---|
200 | \section2 Subclassing Complex Widgets
|
---|
201 |
|
---|
202 | Certain standard Qt widgets provide their own support for drag and drop.
|
---|
203 | When subclassing these widgets, it may be necessary to reimplement
|
---|
204 | \l{QWidget::dragMoveEvent()}{dragMoveEvent()} in addition to
|
---|
205 | \l{QWidget::dragEnterEvent()}{dragEnterEvent()} and
|
---|
206 | \l{QWidget::dropEvent()}{dropEvent()} to prevent the base class from
|
---|
207 | providing default drag and drop handling, and to handle any special
|
---|
208 | cases you are interested in.
|
---|
209 |
|
---|
210 | \section1 Drag and Drop Actions
|
---|
211 |
|
---|
212 | In the simplest case, the target of a drag and drop action receives a
|
---|
213 | copy of the data being dragged, and the source decides whether to
|
---|
214 | delete the original. This is described by the \c CopyAction action.
|
---|
215 | The target may also choose to handle other actions, specifically the
|
---|
216 | \c MoveAction and \c LinkAction actions. If the source calls
|
---|
217 | QDrag::exec(), and it returns \c MoveAction, the source is responsible
|
---|
218 | for deleting any original data if it chooses to do so. The QMimeData
|
---|
219 | and QDrag objects created by the source widget \e{should not be deleted}
|
---|
220 | - they will be destroyed by Qt. The target is responsible for taking
|
---|
221 | ownership of the data sent in the drag and drop operation; this is
|
---|
222 | usually done by keeping references to the data.
|
---|
223 |
|
---|
224 | If the target understands the \c LinkAction action, it should
|
---|
225 | store its own reference to the original information; the source
|
---|
226 | does not need to perform any further processing on the data. The
|
---|
227 | most common use of drag and drop actions is when performing a
|
---|
228 | Move within the same widget; see the section on \l{Drop Actions}
|
---|
229 | for more information about this feature.
|
---|
230 |
|
---|
231 | The other major use of drag actions is when using a reference type
|
---|
232 | such as text/uri-list, where the dragged data are actually references
|
---|
233 | to files or objects.
|
---|
234 |
|
---|
235 | \section1 Adding New Drag and Drop Types
|
---|
236 |
|
---|
237 | Drag and drop is not limited to text and images. Any type of information
|
---|
238 | can be transferred in a drag and drop operation. To drag information
|
---|
239 | between applications, the applications must be able to indicate to each
|
---|
240 | other which data formats they can accept and which they can produce.
|
---|
241 | This is achieved using
|
---|
242 | \l{http://www.rfc-editor.org/rfc/rfc1341.txt}{MIME types}. The QDrag
|
---|
243 | object constructed by the source contains a list of MIME types that it
|
---|
244 | uses to represent the data (ordered from most appropriate to least
|
---|
245 | appropriate), and the drop target uses one of these to access the data.
|
---|
246 | For common data types, the convenience functions handle the MIME types
|
---|
247 | used transparently but, for custom data types, it is necessary to
|
---|
248 | state them explicitly.
|
---|
249 |
|
---|
250 | To implement drag and drop actions for a type of information that is
|
---|
251 | not covered by the QDrag convenience functions, the first and most
|
---|
252 | important step is to look for existing formats that are appropriate:
|
---|
253 | The Internet Assigned Numbers Authority (\l{http://www.iana.org}{IANA})
|
---|
254 | provides a
|
---|
255 | \l{http://www.iana.org/assignments/media-types/}{hierarchical
|
---|
256 | list of MIME media types} at the Information Sciences Institute
|
---|
257 | (\l{http://www.isi.edu}{ISI}).
|
---|
258 | Using standard MIME types maximizes the interoperability of
|
---|
259 | your application with other software now and in the future.
|
---|
260 |
|
---|
261 | To support an additional media type, simply set the data in the QMimeData
|
---|
262 | object with the \l{QMimeData::setData()}{setData()} function, supplying
|
---|
263 | the full MIME type and a QByteArray containing the data in the appropriate
|
---|
264 | format. The following code takes a pixmap from a label and stores it
|
---|
265 | as a Portable Network Graphics (PNG) file in a QMimeData object:
|
---|
266 |
|
---|
267 | \snippet doc/src/snippets/separations/finalwidget.cpp 0
|
---|
268 |
|
---|
269 | Of course, for this case we could have simply used
|
---|
270 | \l{QMimeData::setImageData()}{setImageData()} instead to supply image data
|
---|
271 | in a variety of formats:
|
---|
272 |
|
---|
273 | \snippet doc/src/snippets/separations/finalwidget.cpp 1
|
---|
274 |
|
---|
275 | The QByteArray approach is still useful in this case because it provides
|
---|
276 | greater control over the amount of data stored in the QMimeData object.
|
---|
277 |
|
---|
278 | Note that custom datatypes used in item views must be declared as
|
---|
279 | \l{QMetaObject}{meta objects} and that stream operators for them
|
---|
280 | must be implemented.
|
---|
281 |
|
---|
282 | \section1 Drop Actions
|
---|
283 |
|
---|
284 | In the clipboard model, the user can \e cut or \e copy the source
|
---|
285 | information, then later paste it. Similarly in the drag and drop
|
---|
286 | model, the user can drag a \e copy of the information or they can drag
|
---|
287 | the information itself to a new place (\e moving it). The
|
---|
288 | drag and drop model has an additional complication for the programmer:
|
---|
289 | The program doesn't know whether the user wants to cut or copy the
|
---|
290 | information until the operation is complete. This often makes no
|
---|
291 | difference when dragging information between applications, but within
|
---|
292 | an application it is important to check which drop action was used.
|
---|
293 |
|
---|
294 | We can reimplement the mouseMoveEvent() for a widget, and start a drag
|
---|
295 | and drop operation with a combination of possible drop actions. For
|
---|
296 | example, we may want to ensure that dragging always moves objects in
|
---|
297 | the widget:
|
---|
298 |
|
---|
299 | \snippet doc/src/snippets/draganddrop/dragwidget.cpp 7
|
---|
300 | \dots
|
---|
301 | \snippet doc/src/snippets/draganddrop/dragwidget.cpp 8
|
---|
302 |
|
---|
303 | The action returned by the exec() function may default to a
|
---|
304 | \c CopyAction if the information is dropped into another application
|
---|
305 | but, if it is dropped in another widget in the same application, we
|
---|
306 | may obtain a different drop action.
|
---|
307 |
|
---|
308 | The proposed drop actions can be filtered in a widget's dragMoveEvent()
|
---|
309 | function. However, it is possible to accept all proposed actions in
|
---|
310 | the dragEnterEvent() and let the user decide which they want to accept
|
---|
311 | later:
|
---|
312 |
|
---|
313 | \snippet doc/src/snippets/draganddrop/dragwidget.cpp 0
|
---|
314 |
|
---|
315 | When a drop occurs in the widget, the dropEvent() handler function is
|
---|
316 | called, and we can deal with each possible action in turn. First, we
|
---|
317 | deal with drag and drop operations within the same widget:
|
---|
318 |
|
---|
319 | \snippet doc/src/snippets/draganddrop/dragwidget.cpp 1
|
---|
320 |
|
---|
321 | In this case, we refuse to deal with move operations. Each type of drop
|
---|
322 | action that we accept is checked and dealt with accordingly:
|
---|
323 |
|
---|
324 | \snippet doc/src/snippets/draganddrop/dragwidget.cpp 2
|
---|
325 | \snippet doc/src/snippets/draganddrop/dragwidget.cpp 3
|
---|
326 | \snippet doc/src/snippets/draganddrop/dragwidget.cpp 4
|
---|
327 | \dots
|
---|
328 | \snippet doc/src/snippets/draganddrop/dragwidget.cpp 5
|
---|
329 |
|
---|
330 | Note that we checked for individual drop actions in the above code.
|
---|
331 | As mentioned above in the section on
|
---|
332 | \l{#Overriding Proposed Actions}{Overriding Proposed Actions}, it is
|
---|
333 | sometimes necessary to override the proposed drop action and choose a
|
---|
334 | different one from the selection of possible drop actions.
|
---|
335 | To do this, you need to check for the presence of each action in the value
|
---|
336 | supplied by the event's \l{QDropEvent::}{possibleActions()}, set the drop
|
---|
337 | action with \l{QDropEvent::}{setDropAction()}, and call
|
---|
338 | \l{QEvent::}{accept()}.
|
---|
339 |
|
---|
340 | \section1 Drop Rectangles
|
---|
341 |
|
---|
342 | The widget's dragMoveEvent() can be used to restrict drops to certain parts
|
---|
343 | of the widget by only accepting the proposed drop actions when the cursor
|
---|
344 | is within those areas. For example, the following code accepts any proposed
|
---|
345 | drop actions when the cursor is over a child widget (\c dropFrame):
|
---|
346 |
|
---|
347 | \snippet doc/src/snippets/droprectangle/window.cpp 0
|
---|
348 |
|
---|
349 | The dragMoveEvent() can also be used if you need to give visual
|
---|
350 | feedback during a drag and drop operation, to scroll the window, or
|
---|
351 | whatever is appropriate.
|
---|
352 |
|
---|
353 | \section1 The Clipboard
|
---|
354 |
|
---|
355 | Applications can also communicate with each other by putting data on
|
---|
356 | the clipboard. To access this, you need to obtain a QClipboard object
|
---|
357 | from the QApplication object:
|
---|
358 |
|
---|
359 | \snippet examples/widgets/charactermap/mainwindow.cpp 3
|
---|
360 |
|
---|
361 | The QMimeData class is used to represent data that is transferred to and
|
---|
362 | from the clipboard. To put data on the clipboard, you can use the
|
---|
363 | setText(), setImage(), and setPixmap() convenience functions for common
|
---|
364 | data types. These functions are similar to those found in the QMimeData
|
---|
365 | class, except that they also take an additional argument that controls
|
---|
366 | where the data is stored: If \l{QClipboard::Mode}{Clipboard} is
|
---|
367 | specified, the data is placed on the clipboard; if
|
---|
368 | \l{QClipboard::Mode}{Selection} is specified, the data is placed in the
|
---|
369 | mouse selection (on X11 only). By default, data is put on the clipboard.
|
---|
370 |
|
---|
371 | For example, we can copy the contents of a QLineEdit to the clipboard
|
---|
372 | with the following code:
|
---|
373 |
|
---|
374 | \snippet examples/widgets/charactermap/mainwindow.cpp 11
|
---|
375 |
|
---|
376 | Data with different MIME types can also be put on the clipboard.
|
---|
377 | Construct a QMimeData object and set data with setData() function in
|
---|
378 | the way described in the previous section; this object can then be
|
---|
379 | put on the clipboard with the
|
---|
380 | \l{QClipboard::setMimeData()}{setMimeData()} function.
|
---|
381 |
|
---|
382 | The QClipboard class can notify the application about changes to the
|
---|
383 | data it contains via its \l{QClipboard::dataChanged()}{dataChanged()}
|
---|
384 | signal. For example, we can monitor the clipboard by connecting this
|
---|
385 | signal to a slot in a widget:
|
---|
386 |
|
---|
387 | \snippet doc/src/snippets/clipboard/clipwindow.cpp 0
|
---|
388 |
|
---|
389 | The slot connected to this signal can read the data on the clipboard
|
---|
390 | using one of the MIME types that can be used to represent it:
|
---|
391 |
|
---|
392 | \snippet doc/src/snippets/clipboard/clipwindow.cpp 1
|
---|
393 | \dots
|
---|
394 | \snippet doc/src/snippets/clipboard/clipwindow.cpp 2
|
---|
395 |
|
---|
396 | The \l{QClipboard::selectionChanged()}{selectionChanged()} signal can
|
---|
397 | be used on X11 to monitor the mouse selection.
|
---|
398 |
|
---|
399 | \section1 Examples
|
---|
400 |
|
---|
401 | \list
|
---|
402 | \o \l{draganddrop/draggableicons}{Draggable Icons}
|
---|
403 | \o \l{draganddrop/draggabletext}{Draggable Text}
|
---|
404 | \o \l{draganddrop/dropsite}{Drop Site}
|
---|
405 | \o \l{draganddrop/fridgemagnets}{Fridge Magnets}
|
---|
406 | \o \l{draganddrop/puzzle}{Drag and Drop Puzzle}
|
---|
407 | \endlist
|
---|
408 |
|
---|
409 | \section1 Interoperating with Other Applications
|
---|
410 |
|
---|
411 | On X11, the public \l{http://www.newplanetsoftware.com/xdnd/}{XDND
|
---|
412 | protocol} is used, while on Windows Qt uses the OLE standard, and
|
---|
413 | Qt for Mac OS X uses the Carbon Drag Manager. On X11, XDND uses MIME,
|
---|
414 | so no translation is necessary. The Qt API is the same regardless of
|
---|
415 | the platform. On Windows, MIME-aware applications can communicate by
|
---|
416 | using clipboard format names that are MIME types. Already some
|
---|
417 | Windows applications use MIME naming conventions for their
|
---|
418 | clipboard formats. Internally, Qt uses QWindowsMime and
|
---|
419 | QMacPasteboardMime for translating proprietary clipboard formats
|
---|
420 | to and from MIME types.
|
---|
421 |
|
---|
422 | On X11, Qt also supports drops via the Motif Drag & Drop Protocol. The
|
---|
423 | implementation incorporates some code that was originally written by
|
---|
424 | Daniel Dardailler, and adapted for Qt by Matt Koss <[email protected]>
|
---|
425 | and Nokia. Here is the original copyright notice:
|
---|
426 |
|
---|
427 | \legalese
|
---|
428 | Copyright 1996 Daniel Dardailler.
|
---|
429 | Copyright 1999 Matt Koss
|
---|
430 |
|
---|
431 | Permission to use, copy, modify, distribute, and sell this software
|
---|
432 | for any purpose is hereby granted without fee, provided that the above
|
---|
433 | copyright notice appear in all copies and that both that copyright
|
---|
434 | notice and this permission notice appear in supporting documentation,
|
---|
435 | and that the name of Daniel Dardailler not be used in advertising or
|
---|
436 | publicity pertaining to distribution of the software without specific,
|
---|
437 | written prior permission. Daniel Dardailler makes no representations
|
---|
438 | about the suitability of this software for any purpose. It is
|
---|
439 | provided "as is" without express or implied warranty.
|
---|
440 | \endlegalese
|
---|
441 | \omit NOTE: The original version of this copyright notice can be found
|
---|
442 | in qmotifdnd_x11.cpp. \endomit
|
---|
443 |
|
---|
444 | \note The Motif Drag \& Drop Protocol only allows receivers to
|
---|
445 | request data in response to a QDropEvent. If you attempt to
|
---|
446 | request data in response to e.g. a QDragMoveEvent, an empty
|
---|
447 | QByteArray is returned.
|
---|
448 | */
|
---|