New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feh window "moves" upon image change, related to window borders #22

Sadako opened this Issue Jan 2, 2011 · 5 comments


None yet
2 participants

Sadako commented Jan 2, 2011

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.


This comment has been minimized.


derf commented Jan 2, 2011

I used to observe this bug myself when I used fluxbox, good to know what (seems to be) the cause. I'm on vacation right now, but I'll look into it later.


This comment has been minimized.


derf commented Jan 17, 2011

Hm. At least in fluxbox it looks like this is actually a fluxbox and not a feh bug - feh checks the XWindowAttributes border_width when switching images, my dwm correctly reports it as 1 (feh in floating mode), fluxbox has a 0 there. I'll ask the fluxbox devs later.


This comment has been minimized.


derf commented Jan 28, 2011

I'm fairly certain it is a window manager issue, please bug the respective developers :)

@Sadako Sadako reopened this Apr 24, 2011


This comment has been minimized.

Sadako commented Apr 25, 2011

Hey, sorry for being rude about re-opening this, just wanted to be sure I got your attention...

I was messing around with git bisect and the linux kernel, and thought I'd try using it to see if I could figure out when this "issue" was introduced in feh.

Turns out commit 29a9dd9, "Apply 02_changeset_r52_netwm_full_screen.patch from Debian" was the culprit, and reverting that patch solved the issue for me.

The first 3 lines of that commit aren't the issue, just undoing the replacing of the XResizeWindow function call did the trick for me.

You may well be right, considering how this hasn't really been encountered by anyone else it may be a bug in e16 and fluxbox (in their netwm hints code?), haven't encountered anything like this in anything else under e16 though.

Anyways, I'm quite happy with my little patch for this (and I think I've fallen in love with git bisect), just thought I at least owed you the courtesy of letting you know what I found.

Oh, while I'm here; the keybindings config is a fantastic addition, thanks for that.

@ghost ghost assigned derf Apr 25, 2011


This comment has been minimized.


derf commented Apr 25, 2011

I'm quite busy right now, but I'll definitely look into it next week. Just to let you know I read the issue and am not forgetting it ;)

@derf derf closed this in 3810658 May 3, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment