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

[Chris Meyer]

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.

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.

I have sample code I can provide. I'll get it ready. Ultimately something
like a file manager would be a great example.

I'll post these comments on the codereview too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130724/d359db90/attachment.html>