Add:On Linux system support open image in the Trash

[ZTFtrue]

Add a feature on Linux system to support open image in the Trash. Support KDE, gnome, lxde-gtk3, xfce4.

Please check the following before submitting a pull request:

• Fork nomacs and create your branch from master [checked]
• Pull requests are only accepted if they pass travis [checked]

also have a look at our CONTRIBUTING.md

[novomesk]

Hello @ZTFtrue ,

In case there is some issue with this code in the future, are you willing to help finding fixes/solutions?
Do you have plans regarding other contributions to nomacs?

[ZTFtrue]

I'm willing to help finding fixes/solutions for this code in the future. I don't think I have enough time to regarding other contributions, but if i have free time, I will contribute code to nomacs.

…

On Thu, Feb 22, 2024, 23:25 Daniel Novomeský ***@***.***> wrote: Hello @ZTFtrue <https://github.com/ZTFtrue> , In case there is some issue with this code in the future, are you willing to help finding fixes/solutions? Do you have plans regarding other contributions to nomacs? — Reply to this email directly, view it on GitHub <#1030 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADHPP4X4SHQXDKOM3ES3BO3YU5PPTAVCNFSM6AAAAABDJS5BASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJZGY4DGNRYGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[leejuyuu]

The link to trash items seems to be specific to the file manager instead of DE. I am on Arch with Sway WM and nautilus behaves differently from dolphin. Without your patch, Dolphin resolved the path for me when I attempted to open a trashed image with Nomacs, but Nautilus did not.

Did you test with the default file managers for each DE mentioned? (Nautilus for Gnome, Dolphin for KDE, PCManFM for LXDE, and Thunar for XFCE4)
Nautilus, PCManFM, and Thunar use gio/gvfs to manage trash, Dolphin uses a different mechanism that's called KIO slaves

[ZTFtrue]

The link to trash items seems to be specific to the file manager instead of DE. I am on Arch with Sway WM and nautilus behaves differently from dolphin. Without your patch, Dolphin resolved the path for me when I attempted to open a trashed image with Nomacs, but Nautilus did not.

That's because Dolphin can return real path in Gnome DE(just for Gnome DE)

---

Did you test with the default file managers for each DE mentioned? (Nautilus for Gnome, Dolphin for KDE, PCManFM for LXDE, and Thunar for XFCE4) Nautilus, PCManFM, and Thunar use gio/gvfs to manage trash, Dolphin uses a different mechanism that's called KIO slaves

Yes, I tested it, this is the result.

gnome dolphin: https://github.com/nomacs/nomacs/assets/13563890/ad273907-d610-4e17-bf1e-b0c0e323c975
gnome dolphin: https://github.com/nomacs/nomacs/assets/13563890/98ef372e-ca18-4506-930d-462a0ac5e0c7
gnome nautilus: https://github.com/nomacs/nomacs/assets/13563890/e5a3d809-26e2-4cf4-8a92-543daaeaeeb0
Kde dolphin: https://github.com/nomacs/nomacs/assets/13563890/a07908a2-8f70-413e-8edb-a3186de48e74
kde nautilius: https://github.com/nomacs/nomacs/assets/13563890/56636173-b4cb-4495-a399-ab51eddebb59
kde PCManFM: https://github.com/nomacs/nomacs/assets/13563890/c61a1b01-1879-40bc-b40c-675483d4fb9c
Kde Thunar: https://github.com/nomacs/nomacs/assets/13563890/3fe517a9-4f1a-4261-b162-8708084ad793
lxde PCManFM: https://github.com/nomacs/nomacs/assets/13563890/0a0ea565-d38b-4ae7-bf68-ac9c83585e31
XFCE4 Dolphin: https://github.com/nomacs/nomacs/assets/13563890/ff80c769-5a9f-4928-a630-6b79013bd21f
XFCE4 Thunar: https://github.com/nomacs/nomacs/assets/13563890/d1c28d72-8948-4422-8d4e-236865ee8d1a

[leejuyuu]

That's because Dolphin can return real path in Gnome DE(just for Gnome DE)

I do not think so. I am not using Gnome.

[ZTFtrue]

I do not think so. I am not using Gnome.

just for Gnome DE is a mistake.

Dolphin will return the real path in some DE, But this feature will not deal with the real path.

[leejuyuu]

I'm sorry for sounding grumpy. Allow me to explain some of my thoughts.

This feature feels like a "nice-to-have" for me. The problem can already be solved by restoring the trashed image, then nomacs can open it as a normal file. Note that I'm pretty biased since I have stopped using graphical file managers for a while.

Adding support for opening items from the Trash of these file managers will couple nomacs to the handling of the URL schemes, fuse mount points, etc. GTK and KDE applications can understand these URLs because they use gio and kio libraries internally. I could not find clear documentation on how the trash URLs or paths are formatted and resolved, so I suspect that it is expected to use the libraries directly and leave those as implementation details. I feel concerned about using something abstracted away from us by parsing the URLs.

However, if we understand how these things work, we could probably also support other schemes like smb:// instead of just trash://. I'm currently thinking on how things does not work as described in this reddit comment.

[ZTFtrue]

the first pr: #817
I've read the source code for KDE and gnome's default image viewer in the past, and I can't find any clear documentation on how the trash URLs or paths are formatted and resolved, unless using the gio or kio libraries, but this makes difficult to develop and use.

So I tested this feature in any DE and file manager I know so that it can support as many DE as possible. And, I found that there are only two situations, KDE environment and Gnome environment ( Maybe, because many desktop fork of GNOME).

---

For other schemes, maybe we should develop new features.

---

Add On:

gio info can't support trash URLs

[leejuyuu]

I can't find any clear documentation on how the trash URLs or paths are formatted and resolved, unless using the gio or kio libraries

This is what I am worrying about. If it is an implementation detail hidden behind some libraries, it could be changed, and nomacs would need to track and adapt to that change. Also, there might exist different situations that have not been considered in this PR.