source: trunk/doc/src/porting/porting4-dnd.qdoc@ 651

Last change on this file since 651 was 651, checked in by Dmitry A. Kuminov, 16 years ago

trunk: Merged in qt 4.6.2 sources.

  • Property svn:eol-style set to native
File size: 7.3 KB
Line 
1/****************************************************************************
2**
3** Copyright (C) 2010 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 \page porting4-dnd.html
44 \title Porting to Qt 4 - Drag and Drop
45 \contentspage {Porting Guides}{Contents}
46 \previouspage Porting to Qt 4 - Virtual Functions
47 \nextpage Porting UI Files to Qt 4
48 \ingroup porting
49 \brief An overview of the porting process for applications that use drag and drop.
50
51 Qt 4 introduces a new set of classes to handle drag and drop operations
52 that aim to be easier to use than their counterparts in Qt 3. As a result,
53 the way that drag and drop is performed is quite different to the way
54 developers of Qt 3 applications have come to expect. In this guide, we
55 show the differences between the old and new APIs and indicate where
56 applications need to be changed when they are ported to Qt 4.
57
58 \tableofcontents
59
60 \section1 Dragging
61
62 In Qt 3, drag operations are encapsulated by \c QDragObject (see Q3DragObject)
63 and its subclasses. These objects are typically constructed on the heap in
64 response to mouse click or mouse move events, and ownership of them is
65 transferred to Qt so that they can be deleted when the corresponding drag and
66 drop operations have been completed. The drag source has no control over how
67 the drag and drop operation is performed once the object's
68 \l{Q3DragObject::}{drag()} function is called, and it receives no information
69 about how the operation ended.
70
71 \snippet doc/src/snippets/code/doc_src_dnd.qdoc 0
72
73 Similarly, in Qt 4, drag operations are also initiated when a QDrag object
74 is constructed and its \l{QDrag::}{exec()} function is called. In contrast,
75 these objects are typically constructed on the stack rather than the heap
76 since each drag and drop operation is performed synchronously as far as the
77 drag source is concerned. One key benefit of this is that the drag source
78 can receive information about how the operation ended from the value returned
79 by \l{QDrag::}{exec()}.
80
81 \snippet doc/src/snippets/porting4-dropevents/window.cpp 2
82 \snippet doc/src/snippets/porting4-dropevents/window.cpp 3
83 \dots 8
84 \snippet doc/src/snippets/porting4-dropevents/window.cpp 4
85 \snippet doc/src/snippets/porting4-dropevents/window.cpp 5
86
87 A key difference in the above code is the use of the QMimeData class to hold
88 information about the data that is transferred. Qt 3 relies on subclasses
89 of \c QDragObject to provide support for specific MIME types; in Qt 4, the
90 use of QMimeData as a generic container for data makes the relationship
91 between MIME type and data more tranparent. QMimeData is described in more
92 detail later in this document.
93
94 \section1 Dropping
95
96 In both Qt 3 and Qt 4, it is possible to prepare a custom widget to accept
97 dropped data by enabling the \l{QWidget::}{acceptDrops} property of a widget,
98 usually in the widget's constructor. As a result, the widget will receive
99 drag enter events that can be handled by its \l{QWidget::}{dragEnterEvent()}
100 function.
101 As in Qt 3, custom widgets in Qt 4 handle these events by determining
102 whether the data supplied by the drag and drop operation can be dropped onto
103 the widget. Since the classes used to encapsulate MIME data are different in
104 Qt 3 and Qt 4, the exact implementations differ.
105
106 In Qt 3, the drag enter event is handled by checking whether each of the
107 standard \c QDragObject subclasses can decode the data supplied, and
108 indicating success or failure of these checks via the event's
109 \l{QDragEnterEvent::}{accept()} function, as shown in this simple example:
110
111 \snippet doc/src/snippets/code/doc_src_dnd.qdoc 1
112
113 In Qt 4, you can examine the MIME type describing the data to determine
114 whether the widget should accept the event or, for common data types, you
115 can use convenience functions:
116
117 \snippet doc/src/snippets/porting4-dropevents/window.cpp 0
118
119 The widget has some control over the type of drag and drop operation to be
120 performed. In the above code, the action proposed by the drag source is
121 accepted, but
122 \l{Drag and Drop#Overriding Proposed Actions}{this can be overridden} if
123 required.
124
125 In both Qt 3 and Qt 4, it is necessary to accept a given drag event in order
126 to receive the corresponding drop event. A custom widget in Qt 3 that can
127 accept dropped data in the form of text or images might provide an
128 implementation of \l{QWidget::}{dropEvent()} that looks like the following:
129
130 \snippet doc/src/snippets/code/doc_src_dnd.qdoc 2
131
132 In Qt 4, the event is handled in a similar way:
133
134 \snippet doc/src/snippets/porting4-dropevents/window.cpp 1
135
136 It is also possible to extract data stored for a particular MIME type if it
137 was specified by the drag source.
138
139 \section1 MIME Types and Data
140
141 In Qt 3, data to be transferred in drag and drop operations is encapsulated
142 in instances of \c QDragObject and its subclasses, representing specific
143 data formats related to common MIME type and subtypes.
144
145 In Qt 4, only the QMimeData class is used to represent data, providing a
146 container for data stored in multiple formats, each associated with
147 a relevant MIME type. Since arbitrary MIME types can be specified, there is
148 no need for an extensive class hierarchy to represent different kinds of
149 information. Additionally, QMimeData it provides some convenience functions
150 to allow the most common data formats to be stored and retrieved with less
151 effort than for arbitrary MIME types.
152*/
Note: See TracBrowser for help on using the repository browser.