Cut file command no longer possible when viewing single image
In a previous gThumb version (probably 3.6) it was possible to use Ctrl+X to cut the file currently being shown large even when not in file-thumbnail browser mode. One could then switch to a file browser window (e.g. Nemo or another gThumb instance) and paste the image file there, i.e. trigger moving of the file.
Version 3.11.2 has many advantages like the ability to customize keyboard shortcuts, but although I have Ctrl+X working to cut the selected file(s) in file browser mode (when many small thumbnails are shown), file operations no longer work when viewing a single image.
I found the previous ability to cut the currently shown file very useful for a workflow when reviewing digital photos and making decisions about moving to different (sub)folders for later processing. I am not able to make these decisions by just looking at the small thumbnail, so now I need a lot of Escape & Enter presses to switch back and forth between browser and viewer mode which feels like a usability regression.
There is a more general issue #107 about some possibly missing shortcut, left open even if one may have been fixed, so let me know if I should just have made a comment there. The cut (and copy & paste) shortcuts are not really missing, just limited to a particular mode/scope. I believe copy & paste also worked before when viewing a single image (pasting into the folder) but I'm not missing them for my workflows.
The limitation to "browser view" is documented in https://help.gnome.org/users/gthumb/stable/gthumb-file-copy-move.html.en but previous versions did not have this limitation and I don't see why it would be desirable. If gThumb is receiving notifications from the operating system that the currently viewed file has been moved, gThumb can trigger the command to show the next image instead or fall back to show the file browser if there is no next image. Otherwise, keeping the no longer existing image visible until the user switches to next/previous/browser would not seem like a problem. The user also has the possibility to manually advance to view the next image before triggering any file-system change by pasting the image in another folder.
While researching, I see that in single-image viewer mode, the right-click context menu has an item to "Copy image" (not reacting to the Ctrl+C keyboard shortcut). It turns out that this command is copying image (pixel) data instead of the filesystem path, so after such a copy I can paste it into a Libre Office Writer document but not in the Nemo file browser. However, from gThumb's thumbnail browser mode the "Copy"-command (which responds to Ctrl+C as well as right-click context menu) gives a file:// path works both with Nemo and Libre Office (or does it provide the clipboard with two kinds of MIME-data at once?). One could consider whether "Copy" should be extended to "Copy file" to reduce potential mixups between their effects.
However, I don't expect there to be any ambiguity about the Cut-operation: a Cut-command is intended as a filesystem operation (file remains until pasting a file:// path in an application that implements this to trigger a move-operation) and not a some kind of image-data operation (deleting the file and only keeping the pixel-data on the clipboard for pasting into documents, which would cause loss of data if the user copies/cuts something else before pasting).