DragAndDrop hotspot & cranky-touchpad-drag


#1

DragAndDropContainer::startDragging() allows an image to be specified but, as far as I can tell, the placement of this image relative to the mouse pointer is derived from the mouse position within the control when the drag was started, and there seems to be no public way to change it.

I’m doing a thumbnail-harvester - a sort of dual-pane image browser to collect images from various resources - and for this sort of work, it seems more natural to have the dragged thumbnails centered than to have their alignment determined by the mouse coordinates at drag start. I could imagine other uses - such as dragging pins around city maps or plugs into outlets, or tail-on-donkey - where one might prefer to have the mouse pointer on a specific pixel of the image, perhaps suppressing the normal mouse arrow while dragging.

Also, I wonder if click-click-dragging is possible. Don’t know if this term is proper English, what I mean is, I’d like to be able to use a drag mode where, instead of keeping the mouse button down when dragging, one click starts the dragging and another click ends it. (With the touchpads of the cheap subnotebooks we use in our living-lab experiments, click-move-click is somewhat easier than press-move-release.)


#2

Oddly enough I was running into the inverse problem a few days ago. I was adding Word style drag and drop support to the JUCE TextEditor, and as such needed to provide a custom image with just the selected text. In this case, JUCE arbitrarily places the image horizontally centered on, but just above the mouse pointer.

In this case, rather than centered, I’d need to be able to arbitrarily position the drag image. Perhaps we just need an extra method to override the default image offsets?

On a kind of related note. Drag and drop targets can cause the drag image to be hidden. It’d be useful if they could also temporarily replace it. In this way, the target could express how it understands the item hovering above it. Obviously you can do this with custom paint methods in the target, but if the target is small, and the desired image is larger, then things get to be more difficult quite quickly.

Re: the click-drag-click thing, can’t you achieve this fairly painlessly with appropriate implementations for mouseDown() and mouseUp() on the source and destination components?


#3

Yes, I should probably allow some more control over the image position. Will put it high on my to-do-list.

Not really possible - when you move the mouse out of a window without the button held down, your app loses control of it, so won’t be able to catch the next mouse-down. If you only needed dragging within your own window, then you could get it working, but it wouldn’t bear much resemblence to the current implementation.


#4

May I suggest you make the DragImageComponent in juce_DragAndDropContainer.cpp public, and instantiate it in a protected virtual method of DragAndDropContainer? This would make the dragging logic customizable by subclassing, in a style similar to the use of custom controls for list items.


#5

Argh… it’s the TabbedComponent that provides this feature, by its protected createTabButton method.


#6

Possibly. I’ll have to have a look and a think.