Drag and Drop to extract does not work under wayland

[Arnaudv6]

Drag and Drop to extract does not work under wayland, same as
https://gitlab.gnome.org/GNOME/file-roller/-/issues/4

[iMonZ]

@raveit65 even if he ignored the template can this issue still be addressed?
I would say this is one of the most important issues right now with engrampa.

[Arnaudv6]

I'd love to be proven wrong, but I think this ain't going anywhere.
https://gitlab.gnome.org/GNOME/file-roller/-/issues/4#note_1076330
even though engrampa is not exactly file-roller, it is a fork, an X-app, and will likely die too? @raveit65?

For what it's worth, I've been using a combination of:
xarchiver, through Xwayland, which is lightweight
and archivemount by cybernoid, based on gvfs-archive to open archives as readonly in thunar.

[benyaminl]

@Arnaudv6 when xarchiver on xwayland, are you even able to drag and drop?

EDIT: I only able to drag from thunar to xarchiver, but not from xarchiver to thunar sadly

[lukefromdc]

Looks like lxqt's archiver works but is slow and iffy, and any fix for file-roller will be for the GTK4 version with a different drag and drop API. Thus we are not likely ever to have a file-roller commit to pull code or even an algorithm from.

[benyaminl]

Looks like lxqt's archiver works but is slow and iffy, and any fix for file-roller will be for the GTK4 version with a different drag and drop API. Thus we are not likely ever to have a file-roller commit to pull code or even an algorithm from.

Wow, are they using different protocol to drag and drop files? Interesting

Thanks for sharing @lukefromdc

[lukefromdc]

xarchiver I'm pretty sure is another file-roller fork. Thus same results: you can drop something into an archive (drop target is inside the program's window) but you cannot drag it from inside the archive (and the window for it) to anything else. I just found that at least in Engrampa under wayland you can drag a file from one archive to another (two engrampa windows). These are two separate instances of Engrampa, so at least under this condition it can find a valid drop target.

[mark-herbert42]

Yes - exactly same I've checked now - to make sure both engrampa windows dont use Xwayland I've unset the display variable - so they both are Wayland native. And it is OK - the drag-drop is fine between them, and I can even drop to a folder I want within the archive. So it is not the issue with gdk_property_get call that was mentioned in the fr bug tracker. I've injected the debug message into fr_window_folder_tree_drag_data_get function - actually this function is just connected to a signal drag_data_get as a callback. And - it just is not called. When I drag-drop between 2 engampas I see drag_begin, drag_data_get, drag_end calls. If I try to drag-drop from engrampa into caja - the drag_data_get callback never runs. Same thing when I do drag-drop from Engrampa to Thunar - so seems that the issue is not in caja but in engrampa itself.

But so far my knowledge is not enough whe the drag_data_get callback is not triggered under Wayland with caja, but triggered with engrampa to engrampa transfer. I have studied the bug description and was expecting the issue while reading the Xwindow properties instead of gtk drag-drop context, but did not expect that this part of code that FR devs blamed will not be even executed.

[mark-herbert42]

Got the answer for my point - there are 2 widgets file list and tree view, and 2 callbacks for data_get, One widget is connected to signal, one is not so based on which mode is your engrampa in the get data callback is called or not called. And if it is called - the atom can not be read from caja exactly as FR bug report explains. So there is a little bug missing the signal connection for file list and a big bug where caja does not return the destination folder.