Improvements to use it with terminal file managers like ranger about imv

[joedicastro]

Well, I understand perfectly you reasoning, and support it, 'cause at the end it's the UNIX way of doing things, "Do one thing and do it well" and KISS, and I like that.

But it send me again back to square one, the point a of the issue is now unresolved. Let me explain, I can use another tool to do the sort thing, like sort, but as what I need is to sort them alphabetically by their filename (as sxiv or feh does), a simple ls would do the trick. Then, if I do something like this:

$ ls | imv -i

I can see the images in the proper order as it should be, but in order to use it with ranger or other similar tools, if I do something like this:

$ ls | imv image_xx.ext -i

it would show first the desired image and then it would show the rest of the images of the directory sorted, but including again the previous image, then it appears two times and it breaks also the natural sequence.

And if I try something like:

$ ls !(image_xx.ext) | imv image_xx.ext -i

Then the images does not appear two times, because the first one is removed from the initial sorted list, but then the natural order of the sequence is also broken.

As a sort of workaround, the first thing that comes to my mind is to make a little bash/python script to get the index of the desired file from the sorted list, and use the -n option to start at the given image index position (but to do that I would have to consider all the file extensions/types supported by imv to construct the sorted list ignoring the rest of the files, and change that every time that you add a new image type support). Maybe if imv could output all the files that it finds in a recursive search of the directory I could use it to construct the list, then sort it, get the index, and then show them.

Some idea to solve this without so much hassle?

[eXeC64]

The cleanest solution to this, which also makes sense as a feature is to give -n support for being given a path as well as a number, and imv starting at the first instance of that path in the input list.

$ ls | imv -n image_05.png - would be equivalent to you knowing that image_05.png is the third supported item and supplying -n 3. The images would be viewed in the order given by ls of course.

Would that be useful?

Also, just give imv the option - instead of -i to denote images are being listed via stdin. imv is moving to that to fit with other unix tools more. The man page and usage information are supposed to say as much, but it looks like that got accidentally reverted at some point.

[beanaroo]

I thought it might be worth mentioning here for discoverability...

ranger recently included imv in the open_all_images option. Meaning no arguments for imv are necessary.
hut/rangerPOWER@a9f6a0d

[jdiez17]

a should be a matter of calling imv_navigator_add_path_recursive with the base directory of the current image.

We definitely plan to include a thumbnail visualization mode in the future.

[joedicastro]

@jdiez17 yeah you are right, the first thing I tried was to use imv -a -r . image_xx.ext and it works, but it does not open the image_xx.ext file as the first one, it opens the first image file of the directory by alphabetic order. Then I tried now imv -a image_xx.ext -r . and it works fine! So, I missed to try that before open the issue! 😞

Then for rangers users, this would work fine (in rifle.conf file):

mime ^image, has imv, X, flag f= imv -a "$@" -r .

So, first point solved!

[joedicastro]

Still there is something strange, it does not show the images in the same order as sxiv, feh or even a simple ls, which is the criteria used to sort the image files before show them when using the recursive search? It not seems a problem with numbers or case-sensitivity...

I only knew a little C, but seems that you recursive search the directory for images files and not sort the images by filename at any point before show them, isn't it?

[eXeC64]

No sorting is done internally. Currently the best way to sort images is to provide them in the order you wish to view them via another tool, such as sort or shuf. I was under the impression find had built-in sorting functionality which I would have recommended, but it looks like I was wrong.

Sorting functionality is something that could be added as an additional step. I'm reluctant to give imv too much behaviour in that vein though, as sorting by date/size etc. should really be the job of another unix tool. imv ought to be a dumb image viewer that takes what it's given in the order it's given and displays it simply. Searching and sorting files based on different properties is really the work of other utilities.

Perhaps there's an opening in the market for another tool to do just that. Sort a list of input files based on different parameters. I'd call it psort, short for pipe sort.

[joedicastro]

Yes, that would be very useful! 😄 👍

And yes, - is a very extended option between UNIX/Linux tools, and to be frankly, as I read the -i in the man page, I did not thought to use it, but is good to know that is implemented and going to be the default.

[eXeC64]

Fixed, @joedicastro.

[eXeC64]

Neat. I was not aware that had been done.