Order of marked images when passed to key handler

[Jab2870]

Hi, I am currently writing a little script to generate gifs out of images marked by sxiv. I am doing this using the key handler. ctrl+x ctrl+g will launch my script with the marked images passed to stdin.

I would like the images to be passed in the order that I marked them but it seems that they are always sent alphabetically. Is it possible to have them sent to the script in the order that they were selected?

[mschilli87]

@Jab2870: Did you have a look at https://github.com/muennich/sxiv/issues/352? What I mean is are they sent alphabetically or in the order you input them to sxiv (which, by default, is alphabetically)? Anyways I understand your use case and think this could be useful in other cases, too.

[Jab2870]

@mschilli87

Thanks for replying. I normally run sxiv from a bash/zsh shell with something like sxiv *.jpg. If I understand you correctly, it will return them in whatever order the shell expands *.jpg to.

Anyway, so am I right in thinking that currently, there is no way of knowing the order in which the images were marked?

[mschilli87]

@Jab2870:

I was suggesting to replace sxiv *.jpg (which will expand to sxiv bar.jpg baz.jpg foo.jpg) by sxiv foo.jpg bar.jpg baz.jpg. In both cases, you can select foo.jpg first and bar.jpg last and check what you get. In the first case you'd get bar.jpg first (alphabetical ordering) what about the second? My guess is, now you'd get foo.jpg first.

I was just curious because your comment implied that xsiv is ordering the marked images alphabetically but I thought it might just output them in input order.

You are right that this won't solve your use case but it would turn this from a 'please change the way you sort the output' (from alphabetically to by selection order) into a 'please support sorting the output' (by selection order) request. Thus, this simple check (which I could have done myself but was to lazy to) could help to better assess the extend of changes / amount of work your feature request would require.

[taimoorgit]

@Jab I'm not sure about the key handler (never used it for sxiv). Take a look at #363 , I made it so that -o prints in order of selection, you could likely use this for a script or whatever you're trying to do.

[Jab2870]

@taimoorc Thanks, I'll take a look

[taimoorgit]

Let me know if there are any bugs. If you can comment on the pull request I'd appreciate that too.

[xyb3rt]

The order of the selection is not visible and as such I do not want it to have any significance. Instead I'd rather add commands to reorder the image list.

[0ion9]

@muennich : I implemented reordering commands in my fork. The commit factoring is not very good, but the basic operation (main.c: shift_marked_files) is easy to understand on a technical level IMO (memcpy + temp buffers).

I implemented multiple operations and keybound them all:

reorder_marked_images_to_current (placing the marked images before or after the current images) reorder_marked_images (placing the marked images at the end or start of the filelist), reorder_image (moving the current image N slots backward or forward in the filelist), and reorder_image_to_alternate (placing the current image before or after the alternate images)

The usage pattern that emerged suggests that moving marked images as a block to the beginning or end of the filelist is easiest to understand, and 'stacking up' more files after your first pass is simple : keep the existing marks, and mark the images you want to add, then perform the reordering operation again.

I don't personally find reorder_image (the 'move a single image N slots' version) useful, but someone else might. I consider the other two concepts (reorder to alternate, reorder to current) failures as they are too difficult to predict the result of.

'Remove marked images' might also be a complimentary concept -- personally, I implemented that too and then never used it.

If you have any actual plans to implement reordering commands, I hope this helps inform them.