You are not logged in.
Hey,
just posting to point out a potential issue (whether it's a bug is open to interpretation):
Zoom to fit is limited to the minimum zoom found in the zoom_levels array.
For particularly high-res images, this means that zoom to fit does -not- zoom to fit, you need to pan to see the entire image.
In my case at least, this behaviour is undesirable -- zoom to fit should always do exactly what it says, and I do have images that are 16k .. 32k pixels along a dimension.
So, you can fix this by adding a couple more zoom levels to the start of the zoom_levels array. Following the existing pattern, I added 1.5625,3.125, 6.25. That allows zoom-to-fit to correctly handle images that are up to 64 times the resolution of your SXIV window.
Offline
Hello,
I am wondering about a small feature that I would like to see implemented. I do not know how difficult it would be, anyway:
When zooming with the mouse wheel, the image is always zoomed in relative to the center of the image. I would like to have this (as a configurable option at best) to zoom in relative to where the mouse cursor is.
I think that would be a nice enhancement for those people that deal with high resolution images; it allows you to zoom in easily into a specific point of the image.
Would that be too much trouble to integrate?
Thanks,
DrTebi
Offline
Hello,
I am wondering about a small feature that I would like to see implemented. I do not know how difficult it would be, anyway:
When zooming with the mouse wheel, the image is always zoomed in relative to the center of the image. I would like to have this (as a configurable option at best) to zoom in relative to where the mouse cursor is.
I think that would be a nice enhancement for those people that deal with high resolution images; it allows you to zoom in easily into a specific point of the image.
Would that be too much trouble to integrate?
Thanks,
DrTebi
The main complication in implementing this is, you would have to modify the command system so that commands receive an additional argument indicating whether they are being triggered via keyboard or mouse.
Secondarily, you'd probably want to add a function img_zoom_in_to() to image.c to actually perform the zoom+pan. If you look at the related functions in image.c, you can see it would be fairly simple -- just a little additional math to figure out where in the image the mouse cursor is pointing.
After that was done, modifying the command to zoom on the mouse cursor when triggered by a mouse event would be trivial.
Whether this is something that Bert wants to include in vanilla sxiv is another question. Personally (since I never zoom using mouse), I don't have a particular use for this.
Last edited by likytau (2015-08-26 06:41:37)
Offline
Thanks for the quick answer.
I realize that it would be a bit of restructuring, which would complicate things a bit. It would also be best to keep this separate from the keyboard zooming (e.g. in the configuration file), so that a new configuration file would be backwards compatible.
Yet I think it would be great if it would be implemented. I can imagine that there are other users out there that are mostly keyboard users, but prefer the left-hand-on-keyboard, right-hand-on-mouse when browsing images (or editing images in GIMP etc.).
I chose sxiv after I tried many other images viewers, because it is fast and simple, while it still allowed me to configure it entirely to my preferences. It's just that one little thing that I feel could be added It's up to Bert I suppose. Unfortunately my C knowledge is too basic to take it on myself.
Offline
Thanks for the quick answer.
I realize that it would be a bit of restructuring, which would complicate things a bit. It would also be best to keep this separate from the keyboard zooming (e.g. in the configuration file), so that a new configuration file would be backwards compatible.
.. Have you really looked at the config.h file? Mouse events are already separate (defined in 'buttons' array, whereas keyboard events are defined in 'keys'). It's just that commands themselves don't currently get told whether they are being triggered by mouse or not.
Yet I think it would be great if it would be implemented. I can imagine that there are other users out there that are mostly keyboard users, but prefer the left-hand-on-keyboard, right-hand-on-mouse when browsing images (or editing images in GIMP etc.).
That's me too, btw -- except that I have a graphics tablet instead of a mouse, so no scrollwheel.
I chose sxiv after I tried many other images viewers, because it is fast and simple, while it still allowed me to configure it entirely to my preferences. It's just that one little thing that I feel could be added It's up to Bert I suppose. Unfortunately my C knowledge is too basic to take it on myself.
Well, as I understand it that is Bert's motivation in writing sxiv in the simple, minimal way that he has: so that it is easy to add functions and modify it to suit your preferences. Unless I misunderstood him, editing the C code is supposed to be like 'advanced configuration' (whereas editing config.h is basic configuration).
I'm saying that to put it in perspective, I guess: that he's pretty strict about what gets into sxiv in order to maintain this cleanness, so any proposed new functionality needs to make sure it is quite well justified.
From that perspective, he might be willing to add the 'commands get told whether they are being triggered by a mouse or keyboard event' change -- the most involved part of the feature -- but not the 'zoom in to mouse location' feature itself.
Anyway, you should be aware that he reads this thread, but AFAICS pays more attention to the issue tracker. So if you think this feature is suitable for mainline sxiv, I suggest you file an issue about it : https://github.com/muennich/sxiv/issues .
Offline
Hello, I've been using sxiv for some time now, but the key-handler script doesn't work anymore for an unknown reason. When I try to use one combination (C-x then C-d, for example), the bar displays "Running key handler..." and sxiv freezes. Any idea of why?
Last edited by q3cpma (2015-09-04 18:09:55)
Offline
Consider adding -x to the end of the shbang line, eg '!/bin/sh -x', so you can see what lines are being executed. This should reveal what line it is getting stuck at.
Offline
Consider adding -x to the end of the shbang line, eg '!/bin/sh -x', so you can see what lines are being executed. This should reveal what line it is getting stuck at.
It only prints "+ read file" and freezes.
Offline
Fascinating. Have you tried backing up your keyhandler script and replacing it with the example one that comes with sxiv?
If replacing it with the example one results in a working keyhandler, consider whether you would be willing to show us the content of your keyhandler script (via eg. bpaste.net or other pastebin type service).
Offline
I experience the exact same issue with the example script.
Offline
Have you made it executable?
Offline
Yeah. It would probably not print the "+ read file" if not, anyway.
Offline
I'm not sure what else to check, honestly..
* Maybe you could try a different shell in the shbang line (eg zsh or dash)?
* This sounds like a silly question, but is the file set as readable? (and yes, the shbang line appears to be successfully read even if the file is set unreadable. Don't ask me to explain how that works, because I have no idea.)
Offline
"read file" implies you are trying to read a line from stdin into the variable file, that could interrupt your script until it receives a line of input. Can you please share your key-handler?
Last edited by progandy (2015-09-06 12:49:58)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
I'm not sure what else to check, honestly..
* Maybe you could try a different shell in the shbang line (eg zsh or dash)?
* This sounds like a silly question, but is the file set as readable? (and yes, the shbang line appears to be successfully read even if the file is set unreadable. Don't ask me to explain how that works, because I have no idea.)
@propagandy I'm using the wiki one.
Here's a video to illustrate the problem better.
Offline
The wiki is too new. It is based on the git version (sxiv-git in AUR), not the stable that is available in community.
Edit: sxiv 1.3.1 sends the file paths as commandline arguments, sxiv-git sends them as via stdin. The stdin way is described in the wiki.
Edit: /usr/share/sxiv/exec/key-handler always has an example key handler that works with the installed version.
Last edited by progandy (2015-09-06 17:09:05)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Thanks a lot. The wiki should really mention this.
Offline
Yeah, I was unclear in communicating there -- when I said 'the example script' I meant the one that sxiv installs on your system, not one you've gotten off eg. browsing the source tree in github.
I also feel kind of silly for not realizing that 'read file' was supposed to be a command.
Anyhow, for future reference, following bug-reporting etiquette insofar as noting the precise version that you are running can help a lot in resolving these issues quickly.
(In the case of sxiv, running `sxiv -v` reports the version.).
Last edited by likytau (2015-09-07 00:08:38)
Offline
I've just pushed a very simple commit to my clone of sxiv, which may be of interest to anyone currently using the -o option.
This commit implements an -O option, which outputs -all- files remaining in the filelist upon exit, rather than only those that are marked.
IME this is much easier for the use case where you are gradually narrowing down a list of images. And especially is not vulnerable to the 'f%*&, I forgot to select all before quitting, now my list is just empty...' mistake.
EDIT: Note that there currently seems to be an occasional bug with this, where images removed from the filelist are still output. Exactly what triggers it is unclear.
It could even be a bug with the following SpaceFM script I use to filter a filelist:
TMP=/tmp/sxivfilt.$$
sxiv -i -O < "$fm_file" > "$TMP"
# XXX there is still some problem with files removed from filelist hanging around.
# I think I need to trigger a check at exit, or something?
if [ -s "$TMP" ]; then
mv "$TMP" "$fm_file"
fi
but tbh, the above seems very simple.
Last edited by likytau (2015-09-27 05:33:57)
Offline
Hi, just posting to ask about inserting files in the filelist at runtime. Personally, I have decided this is a necessity for dealing with larger filelists.
If you've implemented something like this, I'd appreciate hearing about it.
Currently, I have one idea how to do this: A command that reads the clipboard content, and inserts files in the filelist at the current index.
This approach has a few wrinkles when used in conjunction with keyhandler script.
* Destroys the current clipboard content
* The insertion command following any insertion-orientated keyhandler command must be triggered by xdotool hackery, which is unreliable.
Offline
Hi, just posting to ask about inserting files in the filelist at runtime. Personally, I have decided this is a necessity for dealing with larger filelists.
If you've implemented something like this, I'd appreciate hearing about it.
I rather think you should implement non-blocking stdin input that keeps adding files during the sxiv runtime when new data is available.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Thanks for the idea.
Perhaps I've miscommunicated, though.
Non-blocking stdin could not achieve this as far as I understand, as a) the insertion needs to be triggered via the keyhandler rather than an input stream, and b) the insertion should be at the current cursor location, not end of list.
To give a little context, I am aiming to insert 'headings' in a list of images I'm organizing. So, user presses key, is prompted for string, image is constructed and should be inserted in file list.
Further context to that is that my fork of sxiv includes commands to rearrange the filelist, and an option to output entire filelist at exit, so this 'organising' is actually possible at all.
My current best candidate idea is that sxiv provides the name of a temporary file, and the filelist size, to the key handler, and the key handler can write any number of 'INDEX\nFILENAME' pairs to it (with index='' equalling current cursor pos, index=-1 equalling end of list, etc).
Last edited by likytau (2015-11-26 00:33:00)
Offline
Loving sxiv, since the first run.
Today I needed to search for an image. Rather than going through each directory etc., I figured there must be some command-line trick.
This is what I came up with:
find . -type f -name '*jpg' | tr "\n" "\0" | xargs -0 sxiv -qfbt
It searches for images in the current directory and all sub-directories, then opens sxiv in thumb view with the results.
I am sure there are smarter ways to do this, but this worked for me.
Offline
Loving sxiv, since the first run.
Today I needed to search for an image. Rather than going through each directory etc., I figured there must be some command-line trick.
This is what I came up with:
find . -type f -name '*jpg' | tr "\n" "\0" | xargs -0 sxiv -qfbt
It searches for images in the current directory and all sub-directories, then opens sxiv in thumb view with the results.
I am sure there are smarter ways to do this, but this worked for me.
You definitely want the -print0 instruction to find. Also, usually -iname is safer (some files may be named JPG and won't be found by your -name search)
find . -type f -iname "*.jp[eg]" -print0 | xargs -0 sxiv -qfbt
I also changed the expression so it finds '.jpe' files as well; it still can't find .jpeg.
For complete accuracy, consider using -iregex instead of -name / -iname; it will allow to find -all- jpegs (.jpg/.jpeg/.jpe) . A quick test suggests that "-iregex '.*.jp[eg]g?'" is correct.
...
All that said, are you aware of sxiv's `-r` option? It's usually fine, if you simply want all images in a directory. Non-images are automatically filtered out. The only thing to beware of is that large video files take sxiv a long time to detect as 'not an image'.
Offline
drtebi wrote:Loving sxiv, since the first run.
Today I needed to search for an image. Rather than going through each directory etc., I figured there must be some command-line trick.
This is what I came up with:
find . -type f -name '*jpg' | tr "\n" "\0" | xargs -0 sxiv -qfbt
It searches for images in the current directory and all sub-directories, then opens sxiv in thumb view with the results.
I am sure there are smarter ways to do this, but this worked for me.
You definitely want the -print0 instruction to find. Also, usually -iname is safer (some files may be named JPG and won't be found by your -name search)
find . -type f -iname "*.jp[eg]" -print0 | xargs -0 sxiv -qfbt
I also changed the expression so it finds '.jpe' files as well; it still can't find .jpeg.
For complete accuracy, consider using -iregex instead of -name / -iname; it will allow to find -all- jpegs (.jpg/.jpeg/.jpe) . A quick test suggests that "-iregex '.*.jp[eg]g?'" is correct.
...
All that said, are you aware of sxiv's `-r` option? It's usually fine, if you simply want all images in a directory. Non-images are automatically filtered out. The only thing to beware of is that large video files take sxiv a long time to detect as 'not an image'.
Thanks for these great tips!
The jpeg/jpe/jpg option is not really a concern for me, I have made sure to always rename all images to .jpg.
Regarding the '-r' option, that would not work for me, because I actually have to filter out images that have "lzn" in their filename. These are created by LightZone, the image editor I have been using (they are small preview files with embedded processing instructions for LightZone). Currently I simply filter them out with `grep -v`. Thus my actual `find` line is:
find . -type f -name '*jpg' | grep -v ".*lzn.*jpg$" | tr "\n" "\0" | xargs -0 sxiv -qfbt
That is why I used the `tr` command... I am not sure if I could achieve the same without?
Offline