Bug 425938 - Drag & Drop file from Ark to mpv
Summary: Drag & Drop file from Ark to mpv
Status: RESOLVED DUPLICATE of bug 408233
Alias: None
Product: ark
Classification: Applications
Component: general (show other bugs)
Version: 20.04.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Elvis Angelaccio
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-29 12:13 UTC by Pierre L.
Modified: 2021-11-03 04:11 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre L. 2020-08-29 12:13:35 UTC
SUMMARY
I don't know if it's a Ark or a mpv issue. I can't drag & drop SRT subtitles file from Ark on a video playing in MPV.

The drag & drop of a SRT file works in this situation:
Ark --> Dolphin or desktop --> mpv

But not on this one:
Ark --> mpv

STEPS TO REPRODUCE
1. Play a video with mpv
2. Open a ZIP archive with Ark
3. Try to drag a SRT file of this archive to the mpv window

OBSERVED RESULT
The cursor doesn't allow to drag the file to the mpv window.

EXPECTED RESULT
The subtitle file should be added to the current playing video.

SOFTWARE/OS VERSIONS
Ark: 20.04.3
Linux: Fedora KDE 31 
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.70.0
Qt Version: 5.13.2

ADDITIONAL INFORMATION
Comment 1 Elvis Angelaccio 2020-08-31 00:27:18 UTC
This needs support in mpv. Ark provides a dbus API that mpv can call to trigger files extraction.
Comment 2 Nicolas F. 2020-09-03 04:27:56 UTC
That dbus API is bad. It requires the application to implement Ark-specific handling for drag-and-drop events by making the application tell Ark to extract the file instead of having Ark just extract the file to a temporary location and pass that temporary location to the application through the normal drag and drop mechanism with no involvement of a secondary dbus API to initiate this process.

Is there literally any reason as to why it was misengineered this way?
Comment 3 Elvis Angelaccio 2020-09-05 10:37:21 UTC
(In reply to Nicolas Frattaroli from comment #2)
> That dbus API is bad. It requires the application to implement Ark-specific
> handling for drag-and-drop events by making the application tell Ark to
> extract the file 

I agree it's not good having to write ark-specific code for each app. Ideally there should be a freedesktop specification for this task.
There is https://www.freedesktop.org/wiki/Specifications/XDS/ but I'm not sure if it's what we need.

> instead of having Ark just extract the file to a temporary
> location and pass that temporary location to the application through the
> normal drag and drop mechanism with no involvement of a secondary dbus API
> to initiate this process.
> 
> Is there literally any reason as to why it was misengineered this way?

I can think of one: extraction takes a long time. Doing it like you say would make the implementation much harder. Can be done of course, but someone needs to work on it.
Comment 4 Nicolas F. 2020-09-20 21:22:05 UTC
> I can think of one: extraction takes a long time.

One possible solution is to have Ark expose a temporary fuse mount of the archive. It mounts the archive, passes a filename to the application of that path (i.e. no Ark-specific code is needed) and then keeps around a fuse daemon process while there are still some file handles to it open, plus some grace period for reopening and such. That way, ark only really has to extract as the application reads.
Comment 5 Nate Graham 2021-11-03 04:11:07 UTC

*** This bug has been marked as a duplicate of bug 408233 ***