You are not logged in.
Anyone know a way to simply cancel the recently added external-command-execution prefix key? It looks to me like all you can do in config.h is change the prefix key, not remove it.
(I think prefix keys are cleaner from a programming perspective. But my fingers think they are terrible from a pain perspective)
Offline
dgz wrote:i want a horizontal fit, as in pressing 'e', by default
The constant is called SCALE_WIDTH.
many thanks.
Offline
Anyone know a way to simply cancel the recently added external-command-execution prefix key?
Press Escape.
As for the pain: do you launch external commands from sxiv that often?
Offline
dgz wrote:i want a horizontal fit, as in pressing 'e', by default
The constant is called SCALE_WIDTH.
Feature request: Add this to config.def.h along with the other options!
Offline
likytau wrote:Anyone know a way to simply cancel the recently added external-command-execution prefix key?
Press Escape.
Haha, not what I meant. I meant actually removing the concept of the prefix key.
For now, I've just 'git revert'ed the offending commit.
As for the pain: do you launch external commands from sxiv that often?
1-3 times per image on 33% of images.
Last edited by likytau (2014-02-01 13:19:33)
Offline
I considered that. The reason that doesn't work is that the first move can hit the end of the list followed by the second one hitting the start of the list. As long as the command either a) has no knowledge of the length of the filelist, or b) can't access a command which goes N images through the list without wrapping, it is not mathematically possible. The most randomness reliably achievable with those constraints is .. 'randomly either go to next image or prev image'. Which is not useful
I got around to testing this statistically. resetting to zero, then going forward randint(1,50000) items was the best algorithm I could find -- somewhat better than (back+forward), and it arrives at list end roughly 50% of the time, and 90% through the list roughly 15% of the time.
(log10 plot, 99 (on the right) has a frequency of 3568, 90 has a frequency of 1012. The lower area ranges between 8 and 36. X values are normalized to [0..100])
Offline
is it possible to set horizontal fit as default in config.h or (even better) via a startup option.
this is useful for viewing manga and comics.
Now it is: https://github.com/muennich/sxiv/commit … d80d11c9df
We've also got a new keymapping: 'W' fits image to window: https://github.com/muennich/sxiv/commit … c0f3e73708
Offline
Very odd issue: when rotating with ctrl+comma, the image isn't rotated properly every time.
This video is worth a millon words:
http://assets.hugoosvaldobarrera.com.ar … /funny.ogg
As you can see, see, the border on the image get put in the wrong place at a certain rotation. It's also saved like that, not just rendered. What's even funnier is that rotating again, returns it to it's original shape!
Here's the image in case you want to try it out yourself.
I used all the default settings, current community version.
[EDIT]
Ok, so I fiddled with sxiv long enough, and I've decided it's got everything I need. So long and goodbye gpicview, welcome sxiv. I remember having tested this ages aog, and rotatin didn't keep the exiv tags. It does now Thanks a lot for this great app!
Last edited by hobarrera (2014-02-19 21:01:33)
Offline
[EDIT]
Ok, so I fiddled with sxiv long enough, and I've decided it's got everything I need. So long and goodbye gpicview, welcome sxiv. I remember having tested this ages aog, and rotatin didn't keep the exiv tags. It does now Thanks a lot for this great app!
FWIW, picture (as opposed to view) rotation is actually done via jpegtran. The change you observed is probably just a matter of providing the "-copy all" option to it (see the exec/key-handler script).
This also means that the bug you observed (which I can reproduce, btw) is almost certainly part of jpegtran. Consider filing a bug against libjpeg-turbo (at least, this is the owner of /usr/bin/jpegtran on my system)
Last edited by likytau (2014-02-20 06:50:39)
Offline
[EDIT]
Ok, so I fiddled with sxiv long enough, and I've decided it's got everything I need. So long and goodbye gpicview, welcome sxiv. I remember having tested this ages aog, and rotatin didn't keep the exiv tags. It does now Thanks a lot for this great app!FWIW, picture (as opposed to view) rotation is actually done via jpegtran. The change you observed is probably just a matter of providing the "-copy all" option to it (see the exec/key-handler script).
Maybe sxiv didn't provide the "-copy all" argument at the time? I can't really report the issue now, that was over a year ago, and it's no longer reproducible.
I do wish I had looked into that argument so many months ago. I could have been using sxiv all this time!
Offline
likytau wrote:[EDIT]
Ok, so I fiddled with sxiv long enough, and I've decided it's got everything I need. So long and goodbye gpicview, welcome sxiv. I remember having tested this ages aog, and rotatin didn't keep the exiv tags. It does now Thanks a lot for this great app!FWIW, picture (as opposed to view) rotation is actually done via jpegtran. The change you observed is probably just a matter of providing the "-copy all" option to it (see the exec/key-handler script).
Maybe sxiv didn't provide the "-copy all" argument at the time?
That is exactly what I'm saying.
I can't really report the issue now, that was over a year ago, and it's no longer reproducible.
Uh no, the issue I'm talking about is, I just reproduced it, I rotated your image with ctrl+comma and noticed the artifacts you described, as I said, with current libjpeg-turbo.
Offline
Is it possible to view multiple(2) images at the same time? Didn't see anything like that in the man page and I think it could be useful. Don't see a reason to install a dedicated program for reading comics and such if sxiv does the job almost perfectly.
Offline
Is it possible to view multiple(2) images at the same time? Didn't see anything like that in the man page and I think it could be useful. Don't see a reason to install a dedicated program for reading comics and such if sxiv does the job almost perfectly.
What's wrong with two instances of sxiv to view two images? Seems like the ordinary approach to any file reader that lets you see two of something at a same time.
Offline
What's wrong with two instances of sxiv to view two images? Seems like the ordinary approach to any file reader that lets you see two of something at a same time.
Well, sxiv doesn't read .cbr format, so what I thought was making a dmenu script or something to unpack a chosen file in /tmp and feed the list of images to sxiv for reading. Adding 2 instances of sxiv and manually navigating both seems like a pain.
Maybe I'm just overcomplicating things though, sxiv is great as is no doubt about it and in the end it does what it's supposed to.
Offline
theGunslinger wrote:Is it possible to view multiple(2) images at the same time?
The dual mode of the manga patch might be helpful.
It seems he even added archive reading too, this is exactly what I need. Thank you...
...and Cloudef ofcourse for the patch.
Offline
Thanks for this great tool. I just wish imlib would get svg support some day.
Offline
Here is a small patch that allows slideshow delays of as little as 1 millisecond. Works effectively for running through images very quickly. Note that GIFs always play through once, regardless of slideshow delay - this is the same as the unpatched sxiv, but more noticeable, since all other images may be whizzing past in fractions of a second.
EDIT: also, I want to point out that if you want multiple keyhandlers / image-info handlers, for different tasks, you can do this using the XDG_CONFIG_HOME environment variable. I made a directory ~/.altconfig/tagging/ and copied ~/.config/sxiv to it, then modified the files in exec, and ran sxiv with the alternate config using the command 'XDG_CONFIG_HOME=~/.altconfig/tagging sxiv'
Last edited by likytau (2014-07-14 06:47:59)
Offline
I encounter a minor problem with sxiv since it remembers position of opened images - if image is larger than sxiv window and if image was scrolled down to image's bottom edge then the next image is opened already scrolled down to bottom edge. How to disable that behavior?
Offline
bloom wrote:theGunslinger wrote:Is it possible to view multiple(2) images at the same time?
The dual mode of the manga patch might be helpful.
It seems he even added archive reading too, this is exactly what I need. Thank you...
...and Cloudef ofcourse for the patch.
It lacks the slideshow feature. Does anyone have a patch for this?
Offline
I encounter a minor problem with sxiv since it remembers position of opened images - if image is larger than sxiv window and if image was scrolled down to image's bottom edge then the next image is opened already scrolled down to bottom edge. How to disable that behavior?
just hit = and you'll jump right back to the image being scaled to fit
[site] | [dotfiles] | あたしたち、人間じゃないの?
Offline
I have the same problem as Next7 and I'd rather just press one key to get to the top of the next picture. It should stay scaled to width, but I don't want it to remember the position e.g. viewing the middle or bottom of the picture.
Offline
just hit = and you'll jump right back to the image being scaled to fit
Thanks for the reply but you've missed the point - I do not use scaling and I do not need image to fit.
I solved the issue downgrading to version 1.1.1.
Offline
I have the same problem as Next7 and I'd rather just press one key to get to the top of the next picture. It should stay scaled to width, but I don't want it to remember the position e.g. viewing the middle or bottom of the picture.
The latest commit fixes this with the option to bind a key to multiple actions (navigate to the next image and scroll to the top left).
Offline