[Bug]: Drag'n'drop oddities

[heyup1234]

Before reporting

• I'm on the latest release and the issue still happens.
• I searched existing issues and didn't find a duplicate.

What happened?

This might be me not knowing exactly what is expected, but I am having problems opening a new song by drag'n'drop.

When I drag an audio file and drop it into the input box at the top left of Stemdeck, and click 'Process, it gives the error - Failed to start job: URL must use http or https

When I drag the file elsewhere on the interface, it changes the whole interface screen to a simple player and plays the song. To get back to the main GUI I need to right click and choose back.

I can correctly load a file for splitting using the button at the end of the input box however

Steps to reproduce

In linux, open Stemdeck, open system file browser (Nemo). Drag'n'drop a file onto the Stemdeck interface

Operating system

Linux

StemDeck version

0.17.2

How did you install it?

Linux tar.gz

Logs / screenshots

[thcp]

Thanks for this, and for separating the two behaviours. They have different answers.

The first one is already fixed and waiting on a release. Dropping a file into the box and then pressing Process gave "URL must use http or https" because the box was left holding the file's name, and that button submits whatever is in the box as a link. A filename is not a link, so it failed exactly as you saw. The box no longer holds anything that cannot be fetched, and the button acts on the track rather than on the box. That is merged and goes out in the next release.

The second one is a live bug, and your report is the first I have seen of it. A file dropped anywhere in the window should be caught and treated as a drop on the import box, precisely so the window never turns into the bare media player you had to right click out of. That guard has been in since before the version you are on, so something on your setup is getting past it. That is the part I want to chase.

Three things would help me find it, whenever you have a moment:

1. Does it happen over any part of the window, or only some areas? The library list, the waveform lanes and the bottom bar are worth trying separately.
2. When it flips to the player, is it playing the file you dropped?
3. Which desktop environment are you on, and does it behave the same dragging from a different file manager than Nemo?

In the meantime the button at the end of the box is the reliable way in, as you found.

One thing worth saying plainly: you have opened several of these now and they have been consistently useful, including the one that turned out to be old recordings rather than StemDeck. Please keep going.

[heyup1234]

It seems to open the player no matter where I drop it outside the input box.

Yes, it pays the file dropped.

I am using Linux Mint, with Cinnamon desktop (most common standard setup I believe). I tried three different file managers - all produce the same behaviour.

[thcp]

Thanks for checking all three file managers and confirming it plays the dropped file. That narrowed it down fast, and I was able to reproduce both behaviours with a real drag on Linux.

It turns out both are one bug, which also changes what I said earlier. The box problem is not fixed by the change I mentioned before. It has the same cause as the player.

On Linux, the app's web view never tells the page that a drag carries a file. It describes it as a link. The drop handling only acts on files, so it stepped aside and the web view did its own default thing. Over most of the window that means opening the file, which is the bare player you saw. Over the box it means typing the file's location into it as text, and Process then tried to use that as a web address. Windows and macOS describe the drag as a file, which is why it only happens on Linux.

The fix is in #680. On Linux the app now catches the drop itself and hands the file to the same place the button does. A file dropped anywhere in the window, including on the box, loads just like one picked with the button, and nothing opens in the window anymore. Dragging tracks around inside the library is unaffected.

It will be in the next release. Until then the button remains the way in. Let me know how it behaves once you have it.

[thcp]

The fix is merged, and I tested it successfully on Linux with real drags from a file manager into the app. A file dropped anywhere in the window, including on the box, now loads just like one picked with the button. Nothing opens in the window anymore, and dragging tracks around inside the library still works as before.

It goes out with the next release. Thanks again for the careful reports. Let me know how it behaves on your setup once you have it.

[heyup1234]

All working well now. Drag'n'drop anywhere populates the input box and pressing the button splits them out with no errors.

Thanks !!