Opening a single file opens all files using specific desktop entries

[zsugabubus]

 * 5.0.1
 * Windowed
 * Arch Linux
 * 64 bit

Issue
Opening a single file, either:

• Passes many filenames to a single program. (E.g. %F)
• Starts many programs with single filenames. (E.g. %u)

So basically clicking on a single file behaves like I'd open all files in the directory.

Steps to reproduce

0. Pick a desktop entry file that has Exec=...%F or %u specifiers. (grep %[Fu] -r /usr/share/applications).
1. Open a file with this program and you should face with the above mentioned issue.

Expected behaviour
Only a single program is started with the only selected filename.

Other information
I have updated from 4.8.4, where it worked well.

I noticed this issue with a custom feh.desktop file that has Exec=feh %F. Previously it opened only the selected files (or a single file when I had clicked on a single file), but now it opens all files in the directory.

I deleted my custom desktop file so it used /usr/share/applications/feh.desktop that has Exec=feh %u. Now clicking on a single file opens separate feh processes for each picture in the directory.

[bleck9999]

Can reproduce on arch with nemo 5.0.1, with Exec=feh --start-at %u it opens a seperate process for each file though changing it to Exec=feh %F fixed the issue for me.

[mtwebster]

Can you try running the following command:

gsettings set org.nemo.preferences image-viewers-with-external-sort "[]"

and try to reproduce.

Nemo was changed to allow the sort order in nemo to be maintained when passing multiple files to the image viewer here: 3cb59f8

It seems to fix feh for me (the default is ['xviewer', 'feh', 'sxiv']).

The behavior you're reporting is actually how our xviewer works (and how I expect it to) when opening a single image in a folder, but we shouldn't change existing behavior for other programs.

[bleck9999]

After running the command only the selected image is opened, even after reverting the .desktop file for feh.

[mtwebster]

So I'm curious, why is the new behavior an issue? It's not actually using any more memory (it doesn't load images until they're selected).

I'm somewhat disinclined to change this back, particularly if it is really undesirable for someone, it can be disabled anyhow.

[bleck9999]

Because without changing the desktop entry or the image-viewers-with-external-sort setting it would spawn ~200 windows to open every image in the folder when I only wanted to open one image or pass an excessive amount of arguments to one process.
Personally I'm fine with just using gsettings to disable it, but for what it's worth when using sxiv with external sort enabled it only has the requested image as an argument whether using %F or %u, so this behaviour seems to be specific to feh (for example in a folder with 4 jpg files with %F then it's invoked as feh /tmp/tmp.T5h8T7Lvmr/1.jpg /tmp/tmp.T5h8T7Lvmr/2.jpg /tmp/tmp.T5h8T7Lvmr/3.jpg /tmp/tmp.T5h8T7Lvmr/4.jpg and with %u it's invoked in 4 processes; feh /tmp/tmp.T5h8T7Lvmr/1.jpg, feh /tmp/tmp.T5h8T7Lvmr/2.jpg etc. creating a seperate window for each one)
The behaviour when trying to open a single image with %u is functionally equivalent to selecting every image in the folder and opening with feh, which is undesirable.

[mtwebster]

With 8b9cdfc, I've made this new behavior only apply if the command line accepts a list of files (%F or %U), otherwise the old behavior is kept.

Since only the selected image is loaded even when receiving an entire file list, I've left that behavior alone, as it's essentially the same as previous behavior.

[bleck9999]

👍 Works as expected with %u and external sorting enabled.

[zsugabubus]

Thanks for the quick feedback and fix. Now I understand that is not a bug but a (great) feature.

At first, it was just strange and I thought this behavior is not specific to images but to all kind files.

After all, I think it is good that feh %u does not spawn a few hundred processes accidentally, so this issue report worth something at least. For my part, issue can be closed. Thanks.

[github-actions]

This issue has been automatically marked as stale because it has not had
any activity in over 2 years.

If this issue is still relevant:

• Please test on a current version of this package.
• Add a comment with your findings

If no activity occurs in the next 30 days, this issue will be
automatically closed. Issues can be reopened if needed.

[github-actions]

This issue has been automatically closed due to inactivity.

If you can still reproduce this issue on a current version,
please feel free to reopen it with updated information.