mpv
mpv copied to clipboard
mpv-player
Shift+Drag-and-Drop from Dolphin doesn't work on Wayland
Important Information
Provide following Information:
- mpv version: git master
- Linux Distribution and Version: Arch Linux, 5.13.13
- Source of the mpv binary: mpv-build
- Window Manager and version: kwin + plasma on Wayland, Plasma 5.22.5 on Frameworks 5.85
- GPU driver and version: mesa 21.2.1, amdgpu
Reproduction steps
- Use KDE on Wayland
- Play a file in mpv
- Shift+drag a second file from Dolphin onto mpv
Expected behavior
Dropped file should be queued up at the end of the playlist
Actual behavior
Looks like the shift part of dragging and dropping isn't registering at all, and we're just replacing the currently playing file
Log file
https://0x0.st/-w0h.log
This is probably an issue with kwin somehow not sending us the Shift modifier key in this case, but I'm just reporting it here first to make sure that this isn't some Wayland lolextensions protocol issue.
The same thing happens on sway. I think this is actually on Dolphin to implement. It looks like Dolphin always sends mpv WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY which results in replacing the current file. If it sent WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE, that should result in an append according to the code. Maybe it's hidden in the settings somewhere. I didn't look too hard or try other file managers.
Left a bug report for KDE: https://bugs.kde.org/show_bug.cgi?id=442232
As an aside, the compositor is actually allowed to change the dnd action on the fly according to the protocol which I think should work. So it would not require any code changes from the source application (Dolphin in this case). I'm not sure if anyone currently implements anything like this though.
Compositors may also change the selected action on the fly, mainly in response to keyboard modifier changes during the drag-and-drop operation.
https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_data_offer
I see the same behaviour on KDE in Chromium and Firefox, could be related or needs its own big report?
There's three parts to drag and drop. The source of the DnD (so Dolphin in this case), what receives it (mpv), and finally the actual compositor needs to implement the protocol as well for this all to work. So if any part of this is not correct, then DnD will not be correct. tl;dr maybe it's the same bug or maybe it's not.
Is there any way to override this behaviour?
Like I get that this is going to devolve into a blame game of who's done what wrong, but given the option of having just one, the Shift + d'n'd is what I'd like to have. If there was a switch somewhere to swap them around, it'd save us waiting for Plasma to "fix" the "problem".
Is it not fixed actually? The linked issue seems to point to QT which has actually merged a patch related to this. It seems to take into account WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY and WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE glancing at it.
It works if you press shift before dragging a file, so it's related to https://bugs.kde.org/show_bug.cgi?id=423031
Just to give a small update, because KDE Plasma is a buggy shitheap they actually managed to make this worse and now not even holding shift before dragging works. Either way, closing because it's not mpv's problem, but a problem in the incredibly poorly written pile of C++ that is KDE Plasma. What a joke of a fucking desktop environment, but at least it's not GN*ME.
Just to give a small update, because KDE Plasma is a buggy shitheap they actually managed to make this worse and now not even holding shift before dragging works.
Charming.
Either way, closing because it's not mpv's problem, but a problem in the incredibly poorly written pile of C++ that is KDE Plasma.
- You should close this as not planned. The issue is still present. It's just that you don't plan to fix it.
- You shouldn't close this, because
mpvcan fix this problem. Namely, add a config parameter that allows you to trigger the "add" functionality without holding shift. - Just because it's a problem in another project, doesn't mean it's a good look for your project to wontfix an issue that can well stay open and just be closed when the issue in the other project is fixed.
- Evidently, the issue is of agreeing on an API, because KDE's Dolphin seems to be perfectly capable of parsing Shift-drag as separate from drag.
- This issue is not exclusive to KDE, and there are projects other than
mpvthat seem to resolve it, suggesting thatmpvis at least partly culpable. - Denigrating other projects (which massive in scope, contain multiple voluntary contributions and don't have the luxury of regular maintenance) is not a good look for your project. Yes, KDE's code base is problematic. Any project of that size would have such problems. A project of that size evidently is in high demand. Behave like a grown person, and treat your users with some respect.
Evidently, the issue is of agreeing on an API, because KDE's Dolphin seems to be perfectly capable of parsing Shift-drag as separate from drag.
I'm surprised it's that complex in a native program, while it is pretty simple to detect in modern browsers with JS.
I took another look at this and there's probably some changes I should make for purely logging reasons (you can get some misleading messages), but fundamentally the issue is still that mpv always receives COPY.
I also can't get a Dolphin-to-Dolphin drag-and-drop to recognise any modifier keys now, so it's 100% something broken on KDE's side and not a matter of a disagreement over protocol or whatever.
I also can't get a Dolphin-to-Dolphin drag-and-drop to recognise any modifier keys now, so it's 100% something broken on KDE's side and not a matter of a disagreement over protocol or whatever.
Given the direction of the conversation, I'd hesitate to say anything is 100%. There are variables for which you cannot control, variables which might take time to discover, and variables which when made apparent might be embarrassing.
Still I'll err on your side, and pretend that I cannot do Dolphin to Dolphin drag and drop. But instead invite the question of why can't you make drag and drop without the modifier do the same thing? Make it a config parameter, give us a workaround?
Additionally, while I understand the occasional frustration, and that some large projects have made baffling decisions. Is this form of antagonism necessary?
Adding a hack to workaround something that should just be fixed in the other application isn't really appealing.
I'd prefer non-shift as append in any case. There's value in making this behaviour configurable outside any workarounds, imho.
I guess it could be a global option to replace/append by default and apply it to any platform in theory.
Adding a hack to workaround something that should just be fixed in the other application isn't really appealing.
I prefer to think of it as a continuation of the modular, customisable API design. Having the ability to rebind space is not in any way different from rebinding drag'n'drop.
Should we open a separate issue and mark this as "has workaround" citing the new functionality? Hell I don't mind writing the PR myself, if you agree to review it.
Having the ability to rebind space is not in any way different from rebinding drag'n'drop.
That's not possible on wayland. There's no way to know what modifier is pressed.
That's not possible on wayland. There's no way to know what modifier is pressed.
Maybe I need to paraphrase.
I can bind Space to quit mpv if I want to. It’s still spacebar, that I need to press, but the target function is different.
Similarly, I would like to also be able to swap the action that would be triggered on shift drag with the action that is triggered on the normal drag’n’drop. That is more than possible because it does not depend on Wayland, it’s strictly based on exposing a config param that changes the behaviour of a regular drag’ event.
Similarly, I would like to also be able to swap the action that would be triggered on shift drag with the action that is triggered on the normal drag’n’drop.
mpv doesn't have any knowledge of what keys are being pressed or anything like that. It just knows it received data, that's it. The only thing that could theoretically be done is adding a setting that just ignores whatever action we get from the compositor and always either do a replace or append.
We don’t seem to be understanding each other.
I understand that the compositor might send different actions instead of raw modifiers + drag’n’drop event. I don’t mind that due to bugs, not all events can be triggered. This is true, and irrelevant.
I want an option inside MPV that changes how MPV interprets the event that is supported by compositors.
Namely I want to replace the action of killing my playlist and starting from the first entry, with the action that appends the files to the playlist, when I do a regular drag and drop.
MPV doesn’t need to know what keys are pressed. It needs to receive the files and append them to the playlist, without starting to play the first file, or clearing the playlist.
It needs to receive the files and append them to the playlist, without starting to play the first file, or clearing the playlist.
That's exactly what Dudemanguy has being saying for the past 10hrs or so.
I want an option inside MPV that changes how MPV interprets the event that is supported by compositors.
That would be the global option that ignores the event action like I said.
@garoto
for the record,
- it’s closer to three hours,
- the only reason I went on to elaborate was because of the following statement,
Adding a hack to workaround something that should just be fixed in the other application isn't really appealing.
To which I replied that being able to change the functions triggered by inputs is in no way a hack
- and to
That's not possible on wayland. There's no way to know what modifier is pressed.
That what I request is not specific to wayland, and indeed something which was suggested by @Dudemanguy themselves.
- I wish no further antagonism, and as I said previously, would happily do the work if a PR is accepted.
I would consider closing this issue as completed, because at the very least it has a workaround.