Sxiv: Enable navigating between images after opening an image

[astier]

Currently when sxiv opens a specific image it is not possible to navigate to other images which are in the same directory. This however, is possible in two cases:

1. The directory instead of an specific image is opened
2. Image-number/index which should be opened is given as a parameter as well as the directory

If navigating is possible when the image-number/index is given why shouldn't it be possible when the image-name is given?

I know that there are hacky scripts as a workaround like sxiv-rifle. I also wrote my own wrapper. But I think this feature would be very natural and expected by most people.

[muennich]

The more I think about this the more I feel the urge to rip out all of the code handling directories, even the -r switch because its effect can easily be achieved with -i.

[astier]

I personally don't care that much about sxiv being able to handle directories directly. If I want to open all images within a directory I simply give a regex like * as input. I don't know how other people feel but I think you may be right. sxiv being able to handle directories may be nothing more than syntactic sugar. So go ahead and rip it out. But at least it should be possible to specify which image should be opened/focused first when multiple images are opened.

The default behavior then could be for sxiv image_name that it actually performs sxiv * but focuses image_name first.

Otherwise there could be a special flag which enables to specify which image should be focused. If I would like to open all images starting with 2019_ but want to focus 2019_03_14.png it would be for example sxiv -F 2019_03_14.png 2019_*. The default behavior of sxiv 2019_* would do the same but focus the first image (just what sxiv would do right now).

Would be interesting to hear what other people think.

[mschilli87]

@astier:

Would be interesting to hear what other people think.

My two cents: Simply focus on the first image first.
If you want another one, generate the order you want externally (ls, find, sort, awk, grep/cat, you name it), pipe to sxiv -i and it should open the images you specified in the order you specified, focussing on the first image first. :slightly_smiling_face:

[astier]

@mschilli87 Sure people could do what you suggested. But this wouldn't solve my initial request which is the reason why I opened this issue. Your suggestion would result again in sxiv-wrappers because nobody wants to write long shell-commands each time when s/he wants to open an image just to specify the image-order before being able to open the actual image.

[astier]

Wait. I am sorry. I think this is actually already possible or am I totally off here?
sxiv open_this_image * would open open_this_image first and then all other images. Just the order of the images is then wrong.

[mschilli87]

@astier:

Just the order of the images is then wrong.

Why 'wrong'? It would be the order you pass it.
If you have foo.png bar.png and baz.png, *.png would expand to bar.png baz.png foo.png so

sxiv foo.png *.png

would expand to

sxiv foo.png bar.png baz.png foo.png

Maybe I'm really not seing the actual issue here. :thinking:

---

Your suggestion would result again in sxiv-wrappers because nobody wants to write long shell-commands each time when s/he wants to open an image just to specify the image-order before being able to open the actual image.

What would be wrong about using a simple wrapper function like

sxiv_init () {eval fst=\$$(($1 + 1)); sxiv "$fst" "${@:2}"}

in your ~/bashrc?

This way you could use

sxiv_init 3 *.png

to actually call

sxiv foo.png bar.png baz.png foo.png

.

If you don't like repeating foo.png you could easily modify the above to skip the second time.

[astier]

@mschilli87

Why 'wrong'? It would be the order you pass it.

Yes your are right. It wouldn't be the wrong order. However, it would open the same image twice just as you suggested in your example.

sxiv_init () {eval fst=$$(($1 + 1)); sxiv "$fst" "${@:2}"}

If I put it in my bashrc and source it my bash complains syntax error near unexpected token {eval. I am not very proficient in bash so I am not sure whats the issue. However, I get the idea what you are trying to do. I have my own little script which loads all images in a directory and focuses the specified image.

What would be wrong about using a simple wrapper function

Its not necessarily wrong but I think its weird that people first need to write wrappers just to use a program. My reasoning would be that if a feature is requested by so many people (this isn't the first time that this feature is asked for) it should be implemented instead of letting every single person implement its own version of it. I mean this is kind of the purpose of programs. People can reuse them so not everybody needs to reinvent the wheel.

[muennich]

@astier: It‘s okay for my boss to request something from me because he pays me! I get nothing from you and thus I feel no obligation to do anything for you! I’ve made it clear in the README that I write sxiv for myself and not for you! Fortunately, sxiv is open source so that you can do the thing you have requested yourself, you are not limited to requesting and begging. Also, ˋsxiv-rifleˋ was written once and everyone can reuse it.

[astier]

Dear @muennich. If you feel that I made the request to pushy or not friendly enough or if I made you feel like I am expecting from you to work for me or whatever than I can assure you that this was not my intent. I appreciate your effort which you have already made and respect your freedom of choice to decline any request and that you have no obligations to the users of your program.

Its just that if people put their projects into the public with the ability to open issues users generally tend to make use of it which includes feature-requests. If you think only your boss is allowed to make requests (what is different from demanding or expecting something) for a project which you voluntarily put on GitHub then I think you should disable the Issues-Feature on GitHub because as long as people are allowed to open issues there will be requests. However, I think it would be more productive for everybody if in the future you would simply decline them with a friendly NO and close the issue.

Anyway, thanks again for the great work and I hope that we are cool now. Close this issue as you wish.

[sdx23]

@astier: It is one thing to politely ask whether the author would also consider some new feature useful, possibly with a pull request already attached. Every peace of additional code can be a burden to maintain, and I'd understand if muennich decides to throw out directory handling completely (even though I'd be sad about it, because I find it a very useful feature).

It is a different thing to open an issue and keep nagging about something which one knows has been requested (and rejected by the maintainer) a few times in the past. I'm surprised that one could assume this would not come over as pushy.

[astier]

@sdx23

It is one thing to politely ask whether the author would also consider some new feature useful

Thats what I did in my first post. If it wasn't polite enough then I sincerely apologize.

... possibly with a pull request already attached

I don' have a PR but even if I would want to create one I would like first to discuss with the creator if s/he would like to incorporate such a feature. If not writing a pull request would be a waste of time.

I'd understand if muennich decides to throw out directory handling completely

I agreed with muennich and said that I understand that he wants to cut it out. I even liked his post. I don't understand whats the issue here you are trying to bring up.

It is a different thing to open an issue and keep nagging

All my posts except of the first (which was the feature-request) are just follow-ups responding to people. Just as this post is a response to you and not a nagging or begging attempt to implement this feature. If people communicate with me I will respond.

has been requested (and rejected by the maintainer) a few times in the past

Guilty. I saw it now. If this is the reason for all the trouble then sorry for that.

I'm surprised that one could assume this would not come over as pushy.

Only if one assumes all your above statements to be true which are mostly rather your (mis)interpretations (except that the feature was already requested).

Honestly, I will close it now. Didn't know this request would result in such a drama. I respect muennichs time and his decision not to implement this feature.

[doronbehar]

If anyone encounters this issue or #105 which was the original request for this feature, I've worked out a patch that will enable this feature. It's in my fork. Maybe @muennich would be willing to consider adding this feature anyway? If he's interested, I can add another option to the CLI arguments that will disable this behaviour and maybe open a PR with it.

If so, please ping me.

I hope this helps @quite , @astier, @sdx23 , @mschilli87 .

[sammoth]

I also implemented this a while ago. If you want the feature it's worth using an implementation in sxiv because it's orders of magnitude faster on large directories than any method I tried using external scripts or globs.

[doronbehar]

FYI, I've stopped using sxiv and hence I'm afraid I don't see reason to maintain my fork. It's still usable but don't expect any updates on that repo.

[astier]

@doronbehar what are u using now?

[doronbehar]

Gthumb.

[qsmodo]

I implemented this in my fork too. I found that Doronbehar's would duplicate images passed on command line, and that Sammoth's requires the -j for the desired effect. That is not a complaint, just situating possible readers as to why yet another fork. I also added better marks display(#294).