Bug + Patch: Implements drag and drop for plugin windows on Linux

Linux
1

I’ve implemented drag and drop support in JUCE plugin windows on Linux. Previously you could not drop content from outside of the application into JUCE-based plugin windows. This patch fixes things by properly setting up an XdndProxy. Much of the inspiration came from reading the LinVst code.

For us, this gets drag and drop working for some hosts on Linux, specifically:

  • Bitwig
  • Traction

But does not work in:

  • Ardour
  • Reaper

I believe Reaper at one point did support drag and drop, and LinVst has code specifically to make things work with Reaper, but at the moment I’ve not found any examples of D&D working in Reaper. If anyone knows of any, I’d appreciate a note on such so I can look deeper.

I’m attaching the patch, and a screenshot of it working in Sitala (our app). The patch is currently based off of the 5.4.3 tag (as is our app), but could obviously be updated to master without much difficulty.

juce-xdndproxy.diff (5.5 KB)

linux-drag-and-drop
linux-drag-and-drop1438×785 145 KB

https://github.com/decomposer/JUCE/commit/25a547ec289560e12e4eae6c6287ea7d4c24f5b7

7 Likes
2

Actually, I realize now looking at this patch that I don’t need to a getParent() function since I can just use parentWindow – but I haven’t removed it for now since I’m still hoping to get things working in Reaper, where at least in the LinVst code they set a proxy on the grandparent to get things working (though that’s not working for me at the moment).

3

Hi JUCE Team, can you merge this patch to make drag and drop on linux work?

4

Thank you for sharing the patch and bringing this up.

I took a closer look and experimented with the patch on the current develop branch. It seems that presently it’s only working in Bitwig and not even in Waveform anymore.

After playing around with it for a while I’m not convinced this would be a safe approach or one that we could rely on to keep working.

  • The technique only works if it’s the plugin window’s parent window that receives the DND messages. That seems to be the case with Bitwig right now, but it could change as I suspect it has with Tracktion. In AudioPluginHost too, the DND messages are received not by the parent, but another window in which the parent is embedded. There doesn’t seem to be a robust way to discover this from the plugin.
  • Since the plugin window’s parent is created by the DAW, we can’t be sure that hijacking DND calls from it won’t cause a problem down the line.

Since this window hierarchy is managed by the DAWs, I don’t see a way to cleanly and reliably solve the Linux DND problem entirely from the plugin side.