sxiv - Simple image viewer written in C

lolilolicon · 2011-08-20 01:47:23

gorilla wrote:

nXqd wrote:
But I think it's still useful if sxiv draws some information out on the view, in case I use fullscreen mode, I don't have to pop out to see the info
Probably you can write a script for that and bind it to a key in config.h (?)

For that, sxiv needs to support some real "format specifiers" (which feh and [duh] pacman do), instead of one "#" for file path.
Even with that, a script cannot print the information on image, only console output (or some OSD or dzen or whatever, but stdout nontheless).
Personally, I consider the real "format specifiers" more proper than "#", mainly because it provides a better API only requiring small amount of code. Worth the trade-off IMHO.
Drawing that info on image is maybe a little heavy, considering font issues especially with Unicode. I understand if this is not supported.

Last edited by lolilolicon (2011-08-20 01:47:43)

nXqd · 2011-08-20 05:17:37

lolilolicon wrote:

For that, sxiv needs to support some real "format specifiers" (which feh and [duh] pacman do), instead of one "#" for file path.
Even with that, a script cannot print the information on image, only console output (or some OSD or dzen or whatever, but stdout nontheless).
Personally, I consider the real "format specifiers" more proper than "#", mainly because it provides a better API only requiring small amount of code. Worth the trade-off IMHO.
Drawing that info on image is maybe a little heavy, considering font issues especially with Unicode. I understand if this is not supported.

Thanks for your infomation, I just want a more convinient way but I still love the simplicity, it's the top priority. Keep good work

ber_t · 2011-08-20 10:58:37

lolilolicon wrote:

For that, sxiv needs to support some real "format specifiers" (which feh and [duh] pacman do), instead of one "#" for file path.
[...]
Personally, I consider the real "format specifiers" more proper than "#", mainly because it provides a better API only requiring small amount of code. Worth the trade-off IMHO.

For what purpose do you need format specifiers? '#' is only used once throughout the whole code: executing a command line on the current file. The only intention was to give the user the possibility to have some small editing commands, e.g. lossless rotation for jpeg files, afterwards reloading the file to show the result.
So I think that there's only one useful replacement for the exec string (filepath), hence no need for format specifiers.
Or am I missing something? Are there lots of (useful) command lines, which need the file format, file size, image dimension, etc.? If there are not, then I think the simple '#' replacement is all one needs.

I'm on vacation for the next two weeks. I have some pretty nice last feature in the pipeline for the upcoming 1.0 release, which a few people asked me about (hint: it's not the exif autorotation).
I've also refactored the code a bit further, so the 1.0 release will once more break your non-default key/mouse bindings in config.h: i_ / it_ prefixes for the command names, so that one knows, in which mode the commands work in (image or image & thumbnail mode).

lolilolicon · 2011-08-20 12:31:35

ber_t wrote:

So I think that there's only one useful replacement for the exec string (filepath), hence no need for format specifiers.
Or am I missing something? Are there lots of (useful) command lines, which need the file format, file size, image dimension, etc.? If there are not, then I think the simple '#' replacement is all one needs.

Initially, my statement was in direct answer to gorilla's idea of the image info script. Consider that as an example use case
I find the usage of "#" in sxiv has been a bit strange to me all along. I thought, "How can I use a literal # in my command?"
While I don't personally use external commands at all, I do see possibilities where people might want access to some attributes of the current image (and maybe more, like total number of images, PID of sxiv, for example...). My point is, why close a potentially useful API when opening it neither introduces any real drawbacks nor takes much effort? Just for the sake of argument, I will imagine a useful command...

Imagine this... I want to sort images into several directories, based on file path, dimension, and format. I want to do this as I view the images in sxiv, so I can pick only the good ones. I also want the image extensions to be corrected according to the file format (preferably reported by sxiv).

I consider such a command useful. And such a script is easy to write, but requires a little help from sxiv. (True, taking only the file path is OK in this case, but any other info requires another program to open the image file and read again [which sxiv just did... and it refuses to tell me its little secret!])

Make sense to you?

Last edited by lolilolicon (2011-08-20 12:32:40)

saline · 2011-08-20 19:38:07

You could also use imagemagick's identify in your example script to get these details without packing other-things-to-do-well into sxiv...

lolilolicon · 2011-08-21 01:59:43

saline wrote:

You could also use imagemagick's identify in your example script to get these details without packing other-things-to-do-well into sxiv...

lolilolicon wrote:

I consider such a command useful. And such a script is easy to write, but requires a little help from sxiv. (True, taking only the file path is OK in this case, but any other info requires another program to open the image file and read again [which sxiv just did... and it refuses to tell me its little secret!])

saline · 2011-08-21 17:06:51

Plenty of scripts read a file that has already been read and I'm pretty sure most image formats store the relavent info at the top of the file. awk, sed, grep in scripts do plenty of unnecessary reading, I imagine. Why is this the exception?

sxiv is an image viewer. identify will tell you about the image.

Last edited by saline (2011-08-21 17:08:27)

lolilolicon · 2011-08-21 18:13:53

saline wrote:

Plenty of scripts read a file that has already been read [...] awk, sed, grep in scripts do plenty of unnecessary reading, I imagine.

That doesn't mean we are licensed to do it wrong. "Me too" is not a valid reason, generally.

and I'm pretty sure most image formats store the relavent info at the top of the file.

So what? Unnecessary work is unnecessary. And the real expensive part is disk I/O BTW ("There's caching!" OK but that's not the point).

sxiv is an image viewer. identify will tell you about the image.

Oh, that. Then why should sxiv use the imlib2 bloat at all? And you sure hate the about-the-image in the window title, don't you?

fsckd · 2011-08-21 18:24:42

Moderator note: Please be civil and respectful to one another. I'd hate to close an otherwise good discussion. Thanks.

lolilolicon · 2011-08-22 04:27:23

Sorry saline and fsckd if my words have been a little harsh. I don't intend to be a bad-ass, but the expression may have a little too much emotional ingredient in it. Please filter that part out mentally if you dislike the taste. It's nothing personl, saline.

I admit that I was a little uncomfortable to see how often "the Unix philosophy" is being abused to justify laziness or even dumb program. (No offense)

tuxg · 2011-08-23 06:51:00

Hi,
First of all, thank you you've done some amazing work.

I have just a little question/suggestion: do you thought to move to XDG standard directory for cache ?
I don't use the feature but it would be nice to clean the home directory and _I_ think it is simple to implement.

Edit: why don't join the suckless.org project (I dont know if it is possible).

My 2 cents

Last edited by tuxg (2011-08-23 06:53:12)

saline · 2011-08-23 20:34:00

lolilolicon wrote:

Sorry saline and fsckd...

I'm not offended. I understand that we were debating a philosphical difference in program features. I hope I didn't offend. If so, it wasn't my intent and sorry.

ber_t · 2011-08-28 20:04:36

lolilolicon wrote:

I admit that I was a little uncomfortable to see how often "the Unix philosophy" is being abused to justify laziness or even dumb program. (No offense)

As I've already said before: "If you can't live without a certain feature, implement it by yourself and make your changes available to others. If other users like your patch, it might be included upstream."

I write sxiv in my spare time and I write it for myself. I've released it as open-source, because I thought others MIGHT find it useful. I don't owe you anything.

bloom · 2011-09-03 19:57:14

How can I eradicate the following warnings:

commands.c: In function ‘i_navigate’:
commands.c:112:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
commands.c: In function ‘i_navigate_frame’:
commands.c:157:35: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
commands.c: In function ‘i_zoom’:
commands.c:262:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

ber_t · 2011-09-03 21:06:15

@tuxg: Supporting the XDG standard is not really on my agenda.

@bloom: They should be fixed in the current HEAD.

Grinch · 2011-09-04 06:45:20

ber_t wrote:

I write sxiv in my spare time and I write it for myself. I've released it as open-source, because I thought others MIGHT find it useful. I don't owe you anything.

So true, I don't get this new breed of self-entitled spoiled brats. It's as if they think that 'Hey, I did YOU the courtesy of using YOUR free program, now YOU owe ME lifetime support!', just plain scary.

Inxsible · 2011-09-04 09:10:40

Keep the thread on topic and respect all forum members.

I will close this thread if things go worse from here. The Op can then open a new one if he wishes.

ninian · 2011-09-04 11:41:19

ber_t wrote:

I've released it as open-source, because I thought others MIGHT find it useful.

Well, I certainly find Sxiv incredibly useful as is, and am very grateful for it being open-sourced.
It has become my most-used image viewer and I have tried quite a few ...!

avx · 2011-09-05 02:06:09

Dunno if this is too much to ask for, but I'll take a go:

I like the thumbnail-view, but I'd like it even better, if it would be somewhat dynamic in terms of size. Say I call this view on only two images, it would be nice if they'd be represented by bigger thumbs/original size, so it's some kind of 'compare view'.
Ie, for a number of X images, thumbsize could be something like '($resolution - ((X - 1) * $space_between)) / X', if that isn't smaller than the defined thumbsize.

karol · 2011-09-05 02:22:31

avx wrote:

Dunno if this is too much to ask for, but I'll take a go:
I like the thumbnail-view, but I'd like it even better, if it would be somewhat dynamic in terms of size. Say I call this view on only two images, it would be nice if they'd be represented by bigger thumbs/original size, so it's some kind of 'compare view'.
Ie, for a number of X images, thumbsize could be something like '($resolution - ((X - 1) * $space_between)) / X', if that isn't smaller than the defined thumbsize.

You can change the thumbnail size and recompile. It shouldn't take long.

bloom · 2011-09-05 09:54:24

ber_t wrote:

@bloom: They should be fixed in the current HEAD.

I confirm. Thx.

ber_t · 2011-09-05 11:26:51

avx wrote:

I like the thumbnail-view, but I'd like it even better, if it would be somewhat dynamic in terms of size. Say I call this view on only two images, it would be nice if they'd be represented by bigger thumbs/original size, so it's some kind of 'compare view'.

With the current approach the thumbnail cache files have the same size as the displayed thumbnails. This results in a very fast loading time of the cached thumbnails, because they're rendered 1:1, no time consuming scaling is required.

Making the thumbnail size dynamic requires much bigger cache files (half the screen size for your approach?). The cache files (png format) would need much more disk space and the rendering of a bunch of thumbnails would take much longer.

avx · 2011-09-05 12:06:25

I personally don't have caches or better, I've relocated them to RAM (SSD should not get trashed). Isn't there a way just to scale them, you know, like in HTML where you define w/h and the image gets scaled on the fly?

bloom · 2011-09-05 12:16:17

sxiv can't play this animated GIF :

http://cl.ly/9sET

Last edited by bloom (2011-09-05 14:28:43)

karol · 2011-09-05 12:44:16

bloom wrote:

sxiv can't open this GIF :
http://cl.ly/9sET

https://bbs.archlinux.org/viewtopic.php … 38#p889638

ber_t wrote:

Sorry, but I also do not plan to implement gif animation support. Please have a look at gifview, which comes with extra/gifsicle.

Static gifs work just fine.

Arch Linux

#201 2011-08-20 01:47:23

Re: sxiv - Simple image viewer written in C

#202 2011-08-20 05:17:37

Re: sxiv - Simple image viewer written in C

#203 2011-08-20 10:58:37

Re: sxiv - Simple image viewer written in C

#204 2011-08-20 12:31:35

Re: sxiv - Simple image viewer written in C

#205 2011-08-20 19:38:07

Re: sxiv - Simple image viewer written in C

#206 2011-08-21 01:59:43

Re: sxiv - Simple image viewer written in C

#207 2011-08-21 17:06:51

Re: sxiv - Simple image viewer written in C

#208 2011-08-21 18:13:53

Re: sxiv - Simple image viewer written in C

#209 2011-08-21 18:24:42

Re: sxiv - Simple image viewer written in C

#210 2011-08-22 04:27:23

Re: sxiv - Simple image viewer written in C

#211 2011-08-23 06:51:00

Re: sxiv - Simple image viewer written in C

#212 2011-08-23 20:34:00

Re: sxiv - Simple image viewer written in C

#213 2011-08-28 20:04:36

Re: sxiv - Simple image viewer written in C

#214 2011-09-03 19:57:14

Re: sxiv - Simple image viewer written in C

#215 2011-09-03 21:06:15

Re: sxiv - Simple image viewer written in C

#216 2011-09-04 06:45:20

Re: sxiv - Simple image viewer written in C

#217 2011-09-04 09:10:40

Re: sxiv - Simple image viewer written in C

#218 2011-09-04 11:41:19

Re: sxiv - Simple image viewer written in C

#219 2011-09-05 02:06:09

Re: sxiv - Simple image viewer written in C

#220 2011-09-05 02:22:31

Re: sxiv - Simple image viewer written in C

#221 2011-09-05 09:54:24

Re: sxiv - Simple image viewer written in C

#222 2011-09-05 11:26:51

Re: sxiv - Simple image viewer written in C

#223 2011-09-05 12:06:25

Re: sxiv - Simple image viewer written in C

#224 2011-09-05 12:16:17

Re: sxiv - Simple image viewer written in C

#225 2011-09-05 12:44:16

Re: sxiv - Simple image viewer written in C

Board footer