derf / feh Goto Github PK

--full-screen always scales down images which are too large for the screen.

If --zoom is set, it should maybe not do this...

To fix this issue, I'll first have to decide what I want --scale-down to do exactly (and what not)...

https://derf.homelinux.org/p/feh/ gives 404. You may want update indexes and google is full of this url for feh.

In the function feh_is_kp of keyevents.c, the Shift modifier is ignored by xoring the keystate with 0x1. I believe the NumLock modifier should also be ignored (otherwise, with NumLock activated, no key does anything to feh).

Here is a simple patch: https://bugs.archlinux.org/task/22587?getfile=6325

When handling files with UTF-8 filenames, feh sets the correct window title but doesn't tell X11 it contains UTF-8 / Multibyte chars. This confuses some applications.

In a non-slideshow mode SIGUSR1 or SIGUSR2 could be reused for refreshing the current picture. Now it just simply exits feh..
I use feh as a permanent image display for my projects where the results are bitmaps and I don't want to fiddle with console to run feh.
Now I use the -R parameter but it would be much nicer just to send a signal when my application has just finished modifying the image -> this would help overcome that the -R parameter only accepts integers.

Since 4ddc466, --scale-down often creates windows which are too large when used in floating mode.

I can't find an easy way to start a slideshow at a file's (thumbnail's) position. The only way I can come up with is, create a filelist, then grep it to find the filename's line number, then pipe that line number back into feh to use with --start-at.

I'd like to request an option for feh to do this for me when I ask it to open a single file (but not when I explicitly ask it to open multiple files).

Please adjust feh to work like this:
feh run with no other options should behave as 'feh .'

Thanks a lot
Petr

fluxbox no longer set the background image
change the line 790 of the file options.c to

else if (finalrun && !opt.filelistfile && !opt.bgmode)

solves this bug

See https://bugs.launchpad.net/ubuntu/+source/feh/+bug/607328

An issue is an issue, though I don't consider it urgent. Will be fixed later.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599611

From TODO:
The thumbnail mode draws an image which has to be re-rendered as new
thumbnails are created, becoming quite slow for large filelists.
A workaround (--thumb-redraw) exists, but at some point a rewrite with a
GUI-toolkit or similar (or maybe writing a completely new tool for that and
removing the feature from feh) would be due.

In awesome wm, feh (window mode, not fullscreen mode) blinks at each image switching. I've tried various command line option, but the only way (for me) to solve it is to enable "Freeze Window Size" by mouse click. It would be nice to have a -flag to enable it at startup.

Right now keys have a config file while buttons use commandline options. Fix that.

After deleting a file, feh will still count it when calculating the total shown in the next image. This is fixed by any action causing the image window to be re-rendered.

Like: "1 of 4" -> delete file -> "2 of 4" -> rerender -> "1 of 3"

It would be fantastic if it was possible to apply the --bg-center, --bg-scale and --bg-fill options to the feh window, instead of just the root window. An example where I would find this useful:

feh file.jpg -g "200x500"

When file.jpg is a wide image, there is space left in the window. It would be nice to be able to use an option such as --window-fill to have the image zoomed until it fits the window. This could be useful for viewing collections of almost the same size images that expand to fill the window.

There seems to be a buffer overflow in draw_actions causing problems with certain (hardened) glibc versions.

When opening a large image with feh --scale-down, zoom keys do not behave correctly after pressing the zoom_default key. They instead continue to operate from the previous zoom level

My feh 1.11 completely ignores keypresses. The mouse buttons work as usual.
Feh worked perfectly before I updated. (The version I used before still stored the config-files in ~)

Requested by mail:

Don't go fullscreen, but do make the window as big as possible (either max out width or height) and zoom the image in to fit if necessary.
So, it's like --scale-down, but zooming in, not out.

This can already partially be achieved by combining --auto-zoom and --geometry / the "Freeze Window Size" menu setting.

libpng 1.5.x series is the new stable series. it now turns most if not all of the deprecation warnings from libpng-1.4.x to fatal.

[ .. snipping off unrelated lines .. ]

x86_64-pc-linux-gnu-gcc -march=core2 -msse4.1 -O2 -pipe -Wall -Wextra -pedantic -DPREFIX="/usr" -DPACKAGE="feh" -DVERSION="1.11.2" -Wall -Wextra -pedantic -DPREFIX="/usr" -DPACKAGE="feh" -DVERSION="1.11.2" -c -o multiwindow.o multiwindow.c
feh_png.c: In function ‘feh_png_read_comments’:
feh_png.c:69:6: error: dereferencing pointer to incomplete type
feh_png.c: In function ‘feh_png_write_png’:
feh_png.c:127:6: error: dereferencing pointer to incomplete type
feh_png.c: In function ‘feh_png_file_is_png’:
feh_png.c:197:7: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result
make[1]: *** [feh_png.o] Error 1
make[1]: *** Waiting for unfinished jobs....

[ .. unrelated lines snipped off .. ]

The feh menu is opened as a separate window, which when closed does not return the focus to the main feh windor.

via mail:

I have two problems with --caption-path:

• It tries to create a directory (with an error) on readonly
  filesystems such as CDs
• It creates a subdirectories everywhere I use my theme just to view
  images that will never have a caption.

It shouldn't be necessary to have a read-only theme and a read-write
theme for this. My request is to make --caption-path not create a
directory unless a caption is to be written.

As feh can already rotate images, it would be great if vertical and horizontal flipping were also implemented.
Thanks!
Peter

Xinerama support in the background setting options (--bg-fill et al)

Right now theme options overwrite anything specified on the commandline, this should be reversed.

via hotkey, probably

Requested by mail:

Don't go fullscreen, but do make the window as big as possible (either max out width or height) and zoom the image in to fit if necessary.
So, it's like --scale-down, but zooming in, not out.

This can already partially be achieved by combining --auto-zoom and --geometry / the "Freeze Window Size" menu setting.

Is there a particular reason why feh does not do animated images?

Pretty self-explanatory. I put -D5 in my .fehrc, but sometimes I don't want the slides to change automatically, so when they do, I curse, hit 'h', then 'p'. If I remove the option from my .fehrc, then if I decide I do want automatically changing slides, I have to restart feh.

It shows the dimensions of the cached thumbnails, should be those of the actual images.

There are only three programs using giblib, one of them is feh. And feh only uses a part of giblib. So including those parts into the source and removing the dependency might be an idea

This is kinda difficult to describe, but starting feh with a list of images, each time I change to prev/next image (via the cursor keys, for example), the feh window moves a little down and to the right, and the distance moved appears to be the same as the width and height of the window borders/decorations on the top and left sides...
If I change the feh window to borderless within the window manager it doesn't occur.

This is under e16, but I just checked under fluxbox too and see the same behaviour.

This has been there for I while, I stuck with the old 1.3.4 version (which doesn't exhibit this behaviour) but just tried 1.10 and get the same again.

I'm no programmer, but I'm gonna take a look at the source anyway to see if something in feh is doing this, I'd love to help debug this if I can.

Nice to see feh seeing development again btw, it's one of those little apps I wouldn't want to do without, so it's very much appreciated.

edit: forgot to mention, the same occurs when changing window size after zooming with the 'w' key.

I wonder if anybode actually uses that.

The "x of y" line shown below the filename is limited by the filename length and may be cut off by short filenames.

https://bugs.launchpad.net/ubuntu/+source/feh/+bug/768496

When I try to rotate an image using feh's inplace editing (right-clicking the image,
and chosing "Rotate 90 CW" for example), nothing happens. The picture does not rotate.

Feh does not display any error message, but when I run feh from the command line,
I get the following error message (the picture I'm trying to rotate is called "p1000065.jpg":

---
jpegtran: can't open p1000065.jpg for writing
feh WARNING: lossless rotate: Got exitcode 1 from jpegtran. Commandline was:
jpegtran -copy all -rotate -1076465748 -outfile p1000065.jpg p1000065.jpg

---

When I try to run the jpegtran command directly from the command line,
all I get is the help menu, so the command feh is trying to run isn't working for some reason.

Edited to add:
The reason for this error was that the file I was trying to rotate was read-only.
However, feh didn't give any indication of what the problem was, it just failed silently.
It would be nice if there was some kind of indication why the action failed,
or perhaps the options shouldn't be available when the picture cannot be written.

It's mostly a hack, wget (or maybe a migration to libcurl) do way better.

if a theme (but not normal commandline) contains multiple separate short options (e.g. -x -d instead of -xd), feh gives errors and ignores the first argument specified on commandline, or segfaults if no arguments are specified.
for example:
theme: feh --scale-down -x -d
commandline: feh ~/img.jpg
result: the following errors, and loading all images in . while ignoring ~/img.jpg
feh: invalid option -- '�'
feh: invalid option -- ''

experienced with 1.14.1

When toggling pause via 'h' key, the [Paused] string does not get removed after 2nd key press. Also, a new [Paused]-suffix is appended every time pause is reenabled.
When switching to another image, the prefix is removed, disregarding the current state.

--- feh-1.4.1-orig/src/slideshow.c  2010-03-16 08:06:31.000000000 +0100
+++ feh-1.4.1/src/slideshow.c   2010-03-26 08:43:12.000000000 +0100
@@ -283,20 +283,13 @@ void slideshow_change_image(winwidget wi

 void slideshow_pause_toggle(winwidget w)
 {
-   char *title, *new_title;
-   int len;
-
    if (!opt.paused) {
        opt.paused = 1;
-
-       len = strlen(w->name) + sizeof(" [Paused]") + 1;
-       new_title = emalloc(len);
-       snprintf(new_title, len, "%s [Paused]", w->name);
-       title = estrdup(w->name);
-       winwidget_rename(w, new_title);
    } else {
        opt.paused = 0;
    }
+
+   winwidget_rename(w, NULL);
 }

 char *slideshow_create_name(feh_file * file)
--- feh-1.4.1-orig/src/winwidget.c  2010-03-16 08:06:31.000000000 +0100
+++ feh-1.4.1/src/winwidget.c   2010-03-26 08:52:09.000000000 +0100
@@ -867,10 +867,28 @@ winwidget winwidget_get_from_window(Wind

 void winwidget_rename(winwidget winwid, char *newname)
 {
+   /* newname == NULL -> update current title */
+   char *p_str;
+
    D_ENTER(4);
+   if (newname == NULL)
+       newname = estrdup(winwid->name ? winwid->name : "");
    if (winwid->name)
        free(winwid->name);
-   winwid->name = estrdup(newname);
+   winwid->name = emalloc(strlen(newname) + 10);
+   strcpy(winwid->name, newname);
+
+   if (strlen(winwid->name) > 9) {
+       p_str = winwid->name + strlen(winwid->name) - 9;
+   } else {
+       p_str = winwid->name;
+   }
+   if (opt.paused && strcmp(p_str, " [Paused]") != 0) {
+       strcat(winwid->name, " [Paused]");
+   } else if (!opt.paused && strcmp(p_str, " [Paused]") == 0) {
+       *p_str = '\0';
+   }
+
    winwidget_update_title(winwid);
    D_RETURN_(4);
 }

Like in a file manager: Arrow keys for image selection etc.

With default window title feh just omits unloadable files as I go through the slideshow, but when I use image-only format specifiers ( -^ %h/w/s/p) in window title, feh produces segmentation fault when moving to any unloadable file.
I guess it just should check if file is loadable before updating window title, not only before drawing the image.
(using Gentoo on amd64, checked latest stable and dev version in Portage - 1.9 and 1.11.2 - with same result)

When reloading an image (e.g. via 'r' or SIGUSR1 in multiwindow mode), feh always fails to detect a changed image on the first try.

Mouse buttons can be rebound with --something-button, so why not keys? Although, I'd change the syntax to something like --bind <action> <key> .

From TODO:
On screen 1, it will work if fullscreen is turned off, the window is rendered
and moved so that its top corner is only on screen 1, and then fullscreen is
turned on (after that, it'll work for all images in the slideshow).

For example, this 8bit:
http://vicerveza.homeunix.net/~viric/tmp/prova1.tif

I think 16-bit tiff images also make feh segfault. Floating point images say that imlib2 cannot load them.

At first I thought this was a single-band TIFF image problem but when I starting playing with resizing things I noticed feh becoming happy.. so I started twiddling until I was right between the edge of failing and working:

By massive I mean the original image is: 30691x30661

Playing with resizing to various gets me:
23325x23302 fails (76%)
23018x22995 good (75%)

Next phase was to make sure it wasn't just the TIFF libraries.. so converted the TIFFs to PNG
tifftopnm | pnmtopng >

Same behavior - the 76 fails, 75 works. Trying one more time this time converting to JPG for a last sanity check.

Feh blows up with No Imlib2 loader for that file format on the 76 but the 75 works. Gimp opens both images (in any of the formats) fine (considering the size of the images). XV opens all sizes fine.

I can't distribute the raw (source TIFF) imagery (licensing issue) but I can provide the JPG and PNG files for others to confirm the behavior.

http://beef.gina.alaska.edu/pub/feh-testing/

I put the 75 and 76 as PNG and JPG there along with the original as a PNG.

Running feh 1.9-21-gbeecfaf from github on a FC13 x86_64 machine.

Except for --info, all overlay texts can be toggled on/off. Having this for --info as well would be more consistent.

--reload works for single images, but not for directories

With the use of feh I built a simple Info-Screen with a mini-pc and a samba share from which feh loads images and displays them as a slideshow.

Feh is able to reload a file after an amount of time. But it doesn't reload the content of a folder. I used a script that restarts feh every 10 minutes to make it display files that are uploaded to the samba share while feh is running.

For example,

feh DSCxxxxx.JPG

can view the image. But when type 's' to save it, the console gives:

feh WARNING: Can't save image feh_xxxxxx_xxxxxx_DSCxxxxx.JPG: No such file or directory