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

[Alan Alpert]

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