order of file arguments ignored

[bertsky]

Expected behaviour

Run eom file1 file2 file3.

See file1 first, followed by file2 next, followed by file3 – regardless of path name or date sort order.

Actual behaviour

The files are always sorted alphabetically.

Steps to reproduce the behaviour

Run the CLI on a bunch of files that you want to view in a certain order.

MATE general version

1.20.0

Package version

eom 1.20.0-2ubuntu1

Linux Distribution

Ubuntu 18.04

[lukefromdc]

I managed to duplicate this, by typing eom in terminal, and dragging in three files. The one dragged first (first filename in argument list) did NOT come up as the single image displayed, but did if I use the back and foward buttons to navigate to it.
Indeed, the first file displayed was alphabetically the first.
With this method of running eom, those arrow buttons cycle between the files named in the argument list only. If only ONE file is provided in that argument list, the same buttons cycle through all image files in the directory the file named when eom was opened is in.

[bertsky]

Yes, click-drag and drop is another perspective to the same problem.

I do think the single-image argument behaviour is the right thing.

Just in the multi-argument case, IMHO order should be preserved.

[JorgeStolfi]

I strongly second this request. The order of the arguments is often important, e.g. when showing versionA/image1, versionB/image1 versionA/image2, versionB/image2.

Sorting the file names is quite unexpected and non-standard behavior. Users expect applications to process files in the order given.

If eom did not sort the arguments, users who wanted them sorted could easily do that with Unix piping, e.g. eom 'ls versionA/\*,jpg versionB/\*.jpg | sort\'. On the other hand, with the current eom, there is simply no way for users to display the images in any other order. So, sorting the inputs makes eom less powerful.

Please, just remove that "feature". It will in fact make the code simpler.

[negge]

Also voicing my strong request that this issue is fixed. I just encountered it when I went to compare before and after images using eom before.png after.png and they were displayed in the wrong (!) order.