Dragging and dropping files into mpv *from specifically the desktop* doesn't work

Help
,
1

I just got three short video clips onto my desktop.

If I open mpv (either by opening it stand-alone and then dragging one of the video files into it, or by double-clicking one of the video files), the first video plays. But then if I drag and drop one of the other ones into the mpv window which displays the first video, nothing happens. It ignores the action.

But if I create a folder on the desktop, move the very same video clips into it, and then repeat the exact same procedure, it plays all three videos. It does not ignore my drag and drop events when it’s an actual Dolphin view showing the folder, instead of straight from the KDE Plasma desktop.

In both scenarios, the cursor gets a little “+” marker on it when the mouse cursor is above the mpv window and I’m about to release the mouse button to “drop” it. Yet it only does something when the videos are in the folder and not in the “root” of the desktop.

How is this possible? How can there be different behaviour like this?

2

can confirm it. seems to be a bug in mpv. It works fine in smplay, dragon player or firefox. Should be reported.

/e: not neccessary mpv’s fault.

3

Can’t reproduce it. Both from dolphin or desktop, files are added as playlist.

4

Actually it might be a bug in Plasma or KIO; would need investigation.

The reason for this is that by default, files and folder on the desktop are represented in a slightly different way than usual, in order to change how .desktop files are interpreted when on the desktop (chiefly, to make them prettier, for people accustomed to the Windows approach of sticking shortcuts to apps all over their desktops). A quirk of this is that when you drag something on the desktop, its actual URI is something like desktop:/foo.avi rather than the $HOME/Desktop.foo.avi that you would expect. This URI gets translated by… something… into the normal URI that can be consumed by apps. I can’t remember off the top of my head what that something is.

So it might be that that something is broken right now. Or it might be that MPV has special code to interpret drags from their URI before the translation happens, and so it gets desktop:/foo.avi which of course is not really an actual URL of a network stream anywhere, so then it gives up. Or it could be some other weird interaction between components that individually work fine, but fail when put together (i.e. it’s an “unbounded problem space” challenge)

Needs some investigation.

2 Likes
5

hmm, @dzon is right… it’s pretty odd.

mpv does add files dropped from the desktop to its playlist rather than playing them right away. (< and > to go back and forward)

If these files where dragged from dolphin, it starts a new playlist and plays them right away.

It’s as if two different default actions are set for different locations/URI handlers on Xorg…

/e1: Some update: mpv -v when dragging a file…

  1. from Desktop (x11) → add to playlist
[vo/gpu/x11] DnD type: 'text/uri-list'
[vo/gpu/x11] DnD type: 'text/x-moz-url'
[vo/gpu/x11] DnD type: 'text/plain'
[vo/gpu/x11] DnD type: 'application/x-kde4-urilist'
[vo/gpu/x11] Selected DnD type: text/uri-list

2)from Dolphin (x11) → play new file

[vo/gpu/x11] DnD type: 'text/uri-list'
[vo/gpu/x11] DnD type: 'text/x-moz-url'
[vo/gpu/x11] DnD type: 'text/plain'
[vo/gpu/x11] DnD type: 'application/x-kde4-urilist'
[vo/gpu/x11] DnD type: 'application/vnd.portal.filetransfer'
[vo/gpu/x11] Selected DnD type: text/uri-list
  1. Desktop/Dolphin (wayland) → Play new file
[vo/gpu/wayland] Received a new DND offer. Releasing the previous offer.
[vo/gpu/wayland] Given DND offer with mime type text/uri-list
[vo/gpu/wayland] Accepting DND offer with mime type text/uri-list
[vo/gpu/wayland] DND action is DND_REPLACE

Interestingly all select text/uri-list but behave differently.
Is there a way to intercept the raw contents of the DnD type somehow?