Drag and drop to folders pane causes freeze Linux Fedora 41

[xnview]

currently the only workaround is to use X11

[Kenny Dave]

Okay so it doesn't seem possible to run x11 in Fedora 42. But for the flatpak version, in flatseak, turning off permissions for "Wayland windowing system" and "fallback to x11" seems to be working without freezes on a 5 min check.



Thanks Pierre.

Edit: seems stable on a longer test also. Having issues crashing when an mp4 is selected though, I think that is a different issue.

[dandv]

no problem here on debian or ubuntu...

Ubuntu 25.04, XnViewMP 1.9.3, KDE 6 Wayland. I can reliably reproduce the freeze when:

- dragging a subfolder onto another place in the tree
- dragging a group of files into a folder

[Denyer]

Same issue with KDE Plasma 6 on Wayland under Debian 13. Running the specific executable under XWayland gives a partial workaround, although does mean that some window manager functions won't work.

XDG_SESSION_TYPE=X11 xnview

If running Plasma you can Edit Application on your app menu and put the XDG bit into the environment variables field, although the same may be needed for any file manager actions, etc.

Haven't come across similar issues so far with any other Qt apps that implement drag-and-drop.

edit: Also, it seems to be a one-way issue dragging files between XnViewMP and a file manager such as Nemo. You can successfully drag a file from XnViewMP to Nemo and it'll work. If you drag a file from Nemo to XnViewMP, the file is copied but then XnViewMP hangs/freezes. Is the bug that XnViewMP is waiting for confirmation of the file operation (or something else) to complete so that it can redraw but doesn't get it?

[dandv]

it seems to be a one-way issue dragging files between XnViewMP and a file manager such as Nemo.

I can still reproduce the freeze on Ubuntu 24.04 with KDE 6 Wayland, when dragging a file onto a directory within XNView MP.

The AppImage also crashes when attempting to play MP4 files, but that's another issue.

[Denyer]

Sorry, didn't mean to imply otherwise. I get the following results:

XnViewMP dragging to another location within same instance of XnViewMP - freezes
Nemo file manager to an XnViewMP window - XnViewMP freezes
XnViewMP dragging to another XnView window -- the original is okay but the destination freezes
XnViewMP to a Nemo file manager window -- works

In all cases the file operation seems to complete successfully independently of the freeze behaviour.

So I think the issue is that XnViewMP may be waiting for some sort of signal that it doesn't get. Logically that's either Wayland behaving differently to X11 in terms of signalling, or Wayland itself somehow causing XnViewMP to freeze.

Which is the sort of behaviour that's been seen in other apps sometimes under Wayland, although Chromium is a complex piece of software so it could have been something else entirely there, e.g. https://bugs.kde.org/show_bug.cgi?id=482142

Cutting/copying/pasting via shortcut keys in XnViewMP seems to be a workaround, until the user forgets that drag-and-drop is broken.

If it's Wayland itself that's considered to be the problem then it'd be useful if drag-and-drop file operations could be disabled through an option, since Wayland sessions by default are fast becoming the norm. This thread -- viewtopic.php?t=45990&start=15 -- suggests that's possible although I don't think it's exposed as an option through the GUI and I've just tried putting noDrag=true into the relevant xnview.ini under [Browser] and restarted XnViewMP and it didn't appear to work.