[Development] QtQuick External Drag Drop Partial Patch -- Help Requested

Alan Alpert 416365416c at gmail.com
Wed Jul 24 17:36:39 CEST 2013

On Wed, Jul 24, 2013 at 8:25 AM, Chris Meyer <cmeyer1969+qt at gmail.com> wrote:
> On Wed, Jul 24, 2013 at 1:36 AM, Rutledge Shawn <Shawn.Rutledge at digia.com>
> wrote:
>> On 23 Jul 2013, at 9:16 PM, Chris Meyer wrote:
>> > I've been working on adding support for external drag and drop to
>> > QtQuick. I've created a patch which addresses the basic needs and have used
>> > the resulting capabilities in my non-trivial application to implement drag
>> > and drop between a QtQuick view and a widget.
>> >
>> > I'll need help on one particular feature: generating an image of the
>> > QtQuick item being dragged. Right now it doesn't use any image -- so
>> > dragging works, but the image is just a small gray rectangle.
>> >
>> > In addition, I need feedback on a design choice. I decided to not create
>> > a QtQuick MimeData item; but instead add accessor methods directly to
>> > DropEvent. This seems reasonable, but a future MimeData object could be
>> > re-used if we implement a similar Cut / Copy / Paste functionality. Any
>> > thoughts?
>> >
>> > Finally, I'll need some procedural help to make sure the patch is
>> > suitable to be added for Qt 5.2 -- specifically to make sure I get examples,
>> > tests, and documentation correct.
>> >
>> > Is there someone who has commit access who can help me through this
>> > patch?
>> >
>> > Here is the bug report:
>> > https://bugreports.qt-project.org/browse/QTBUG-27498
>> >
>> > Here is the current code in my patch:
>> > https://codereview.qt-project.org/61017
>> >
>> > It's not complete, but I'm willing to finish it off (with the help from
>> > above). I think this would make a useful addition to Qt 5.2.
>> Yes I will try to help you because it was on my wish list to try to get
>> DnD done for 5.2 if I could find the time, so now you are saving me some
>> work.  ;-)
>> For me it's a bit confusing to have both the Drag attached property and
>> the DragEvent; AFAICT they are similar except that Drag is for the source
>> and DragEvent is for the destination, right?  Maybe it could have been the
>> same type of object on both ends.  But since that API is there, we have to
>> keep supporting it anyway, so probably it's good that this patch is going
>> the direction of being similar whether the dragging is being done within the
>> same application or from an external one.
>> Maybe it would be nice if when receiving a drop, the data being
>> transferred could be handled the same as an ordinary JS object.  Otherwise
>> the reason for all the properties you're adding to QQuickDropEvent is
>> partially to access data from certain keys (text, color, html) and partially
>> to access data of certain types (URLs), right?  It adds convenience for the
>> common use cases.  But DnD implementations are usually supposed to be
>> generic, able to carry data of not-yet-invented types.  And QVariantMap
>> could handle just about anything.  Then when you receive the drop you could
>> iterate the keys, or look for specific keys, and also ask what is the type
>> of each value, depending on how you want to write your application.
>> http://qt-project.org/doc/qt-5.1/qtqml/qtqml-cppintegration-data.html#qvariantlist-and-qvariantmap-to-javascript-array-and-object
>> I'm not sure about this startExternal function either, because it's
>> procedural rather than declarative.  If you would normally call it whenever
>> your mouse cursor is about to leave the window, maybe we could do that
>> automatically.  Or did you expect to call it in some other context?
>> Did you write a suitable example yet?  Otherwise maybe I need to write a
>> quickie file manager/viewer or something like that.
>> I don't know about the drag image yet, but I imagine we can find a way.
>> Anyway we can continue the discussion on codereview too.
> Thanks for getting back to me.
> Regarding the confusion between Drag and DragEvent: I didn't want to change
> the architecture too much. It is also confusing that QtQuick DragEvent is a
> combination of QDragEvent and QDropEvent.
> Regarding a JS object representing the MimeData directly: To construct that
> object, we must extract all the data from QMimeData, which can be large.
> Providing accessor methods allows the user to only extract what they need.
> Also, I'm not sure how we will handle binary data in JS.

I think a good compromise would be to provide accessor methods or a
simple JS object for the common stuff, and one of those access methods
is the QMimeData pointer. You can't handle binary data in JS, but if
we expose a QMimeData* then you can pass that into/from the C++ side
of your application to handle the advanced cases.

> Regarding the startExternal(...) function: I was thinking of providing an
> 'dragType' property which could automatically trigger an external drag. We
> would need an associated 'dragAction' property too.
> Do we need to differentiate between internal and external drags? Then the
> internal/simpler/smoother version can be used until the user drags too far
> out of the way, after which external drag can be used. Maybe we only need
> the external drag technique, but that might affect backwards compatibility.
> It looks like the original DnD implementation (internal only) was done for a
> very specific use case.

Correct. It would be better not to have the internal/external drag
distinction in the end (so long as internal drags are still simple).
Although we do need backwards compatibility, you can mark methods as
deprecated if a new implementation gives it a better replacement.

An important part of removing that distinction would be automatically
starting 'external' drags, i.e. getting rid of the startExternal
function call in the common case.

Alan Alpert

More information about the Development mailing list