XnView Software

Using XnView MP Linux 0.98.2, on Kubuntu 20.04. In the browser, if i Ctrl+X (or manually right-click->Cut) an image, then paste it to Dolphin (KDE's file explorer), the file is duplicated rather than moved. In other words: 'Cut' actually 'Copies' rather than 'cuts.

I can confirm this, but I'm not sure what a "solution" can look like nor how it can be fixed. I'll give my thoughts, and maybe the developer(s) can provide better insight.

This "bug" also happens with GNOME / Xfce / GTK-based file managers, including Thunar and Nemo, and it's not exclusive to Dolphin.

It might be due to the fact that XnViewMP's Browser is missing a common communication between itself and external file managers. When you tell XnViewMP's Browser to "cut" or "copy", it works perfect within itself. However, when you try to bring this "outside", it's as if it cannot "know" whether the copy operation was successful (to Dolphin, Thunar, Nemo, etc), and so for safety reasons it will not delete the original file.

Does that make sense? I'll let the devs chime in on this one.

winnylinny wrote: Tue Apr 06, 2021 1:33 pm It might be due to the fact that XnViewMP's Browser is missing a common communication between itself and external file managers. When you tell XnViewMP's Browser to "cut" or "copy", it works perfect within itself. However, when you try to bring this "outside", it's as if it cannot "know" whether the copy operation was successful (to Dolphin, Thunar, Nemo, etc), and so for safety reasons it will not delete the original file.

Does that make sense? I'll let the devs chime in on this one.

right, i have no way to tell to file manager that operation is a move
It works with default file manager on ubuntu, it uses "x-special/gnome-copied-files"

Could this also be why drag and drop files into subfolder will copy instead of move?

It's the number 1 reason I will not switch to Linux. XnView works better on Windows (bar the constant file locking problem due to Window's atrocious file system)

Oddly enough, The Windows version on linux under WINE works as expected. The Linux version on Linux does not. Every drag and drop into a subfolder will COPY the file instead of MOVE it under Details/Thumbnails views. I have no idea why the different views exhibit different behaviours.

This annoyance is also detering me from donating.

solcuerda wrote: Thu Apr 29, 2021 1:12 am Could this also be why drag and drop files into subfolder will copy instead of move?

from/to thumbnail view?

In either Details or Thumbnails view, when dragging a file into a subfolder, it copies instead of moves. Pressing shift moves it. Supposed to be the other way round. Does it on all flavours of Linux, regardless of Desktop Environment. No idea if the fact I use English (UK) instead of English (US) has anything to do with it. Stranger things have happened!

I'll try to get a video capture of it showing what I mean when I next boot up into Linux.

Thanks to your detailed description I can reproduce the problem.

This problem is supposed to be fixed in XnView MP 0.98.4. Please check and confirm the bug fix here.

Hi Pierre,

Drag & Drop still copies instead of moving, but only with "Details" and "Thumbnails + Details" views. Works as it should with all other views.

Latest Manjaro KDE with everything up-to-date.

Thanks for your continued work on this excellent application.

right issue reopened.

This problem is supposed to be fixed in XnView MP 0.99.0. Please check and confirm the bug fix here.

Unfortunately, the original topic of this thread still seems not to be fixed. If I cut from XnView & paste to Dolphin, the original file remains in its original location (i.e. it copies rather than cuts).

Hi Pierre,

Drag/drop now works as expected. Thanks for fixing that.

Cutting from XnViewMP and pasting into Dolphin does indeed copy, so I can confirm what the OP mentioned. Also, cutting from Dolphin and pasting into XnViewMP also copies. It works as expected with Double Commander and Dolphin.

Is this going to be addressed? It makes xnview very difficult to use on Linux, to the point that I keep having to fire up a whole Windows VM whenever I do a session of organizing.

metal450 wrote: Wed Oct 04, 2023 4:57 am Is this going to be addressed? It makes xnview very difficult to use on Linux, to the point that I keep having to fire up a whole Windows VM whenever I do a session of organizing.

yes the original issue is fixed. If you have always the issue, please describe how to reproduce in a new post...