Some programs remember their current size and position and on next start, they give hints to fvwm (currently running 2.6.5) to open their windows on the exact same position with the same dimensions. My configuration allows those hints.
That works well for most programs, but some don’t get it right in a very specific way.
For example, Evince (my PDF viewer) remembers all that, but it gets the window decorations wrong. On next start, it wants to open its window some pixels moved down (exactly the height of the window title and top border) and some pixels moved right (exactly the width of the left window border). And on next call, the windows is moved again down and right, and again, and again… eventually it no longer opens in the visible area of my screen.
This problem only exists for the position but not for the (inner) window dimensions. The dimensions stay the same and don’t change. Only the position changes.
Evince is one of those programs that tries to disable all window decorations and comes with its own builtin title bar, close button etc. That seems to be the new style guide for GNOME applications. I have an opinion on that but can’t say here because it would require me to use strong language.
My fvwm configuration enforces standard window title and border. Maybe that explains why Evince gets the position wrong. Evince calculates its position without added borders/title, but fvwm interprets the position hint including borders/title.
Is there any way to configure fvwm that it “subtracts” the width and height of its own added window decorations from the position hint given by the software? (That might be useful for all software that tries to disable added window decorations by the window manager.)
You’re not alone
There exists a project on github trying to fix this. But anyway it’s an unbound cheek from the gtk+ developers to decide against the
existing standards and DON’T provide a “no option” to turn this behaviour off … The only way is to use similar applications which isn’t that easy
Hopefully I get that right (configured all that stuff long time ago). I guess it’s “UsePPosition” to allow “evince” to pass through its position hints.
I’m using “TileManualPlacement”.
Cool workaround, unfortunately, my GTK3 version is exactly one of the few that’s not recommended for this little trick. sigh
With “NoDecorHint” I keep “evince” from disabling my standard window title & borders.
In a strange way it seems logical what “evince” does. It disables window title & borders (because it brings its own) and calculates the window position based on this assumption (no added title/borders). “evince” gets confused that there might be window managers which add window title & borders nevertheless.
Although this problem is related to some weird GTK3 stuff, basically more software might be affected by this. Maybe there already is an Fvwm configuration option that subtracts the height/width of the window top/left title/border from any position hint. For those software which doesn’t expect that the window manager may add that later.
Who’s task may it be solve this little dilemma? Is an application able to check if a window manager added title/borders although it was disabled by giving the proper hint? Or is it up to the window manager to recalculate position hints for those applications?
I’ve tried your settings, but within my configuration it doesn’t show your problem
The only thing was with NoDecorHint the titlebar appears additionally
Is it possible to post your config that I can test it directly?
Just found an even simpler way. I’ve started Fvwm 2.6.5 without any configuration (no .fvwm2rc or .fvwm/fvwm2rc), and the problem with Evince is easy to reproduce. By default, Fvwm ignores the decor hint of Evince but it respects the position hint. For every subsequent launch of the same PDF file, the new position changes exactly by the height/width of the added border (which Evince doesn’t expect).
Tested on Fedora 22 (gtk3-3.16.4-2, evince-3.16.1-2) with fvwm 2.6.5 compiled from source.
I ThisWindow (evince) Move w-2p w-24p #hardcoded values of my border and titlebar
Module FvwmEvent FvwmEventMoveEvince[/code]But evince jumps to other places than expected
After some hours of testing with different settings I found the problem: $[w.x]/$[w.y] is smaller than $[cw.x]/$[cw.y]!
Note: $[cw.x]/$[cw.y] return the x/y-geometry of the client part of the window. In other words: the border and title of the window is not taken into account.
This is my echo Output in .xsession-errors][fvwm][Echo]:
w.x: 296
[fvwm][Echo]:
cw.x: 298
[fvwm][Echo]:
w.y: 336
[fvwm][Echo]:
cw.y: 360[/code]
And with this knowledge I found a solution 8)
To prevent that for every available window the function will pass through (yes add_window will be called not only for a new window but for all available windows, too) i set a state for each evince window]
Style evince !State 1
[/code]
The new function looks like this]DestroyFunc FuncMoveEvince
AddToFunc FuncMoveEvince
I ThisWindow (evince, !state 1) PipeRead “echo SetEnv new_x $(($[cw.x]-$[w.x]))”
I Test (!EnvIsSet new_x) break
I PipeRead “echo SetEnv new_y $(($[cw.y]-$[w.y]))”
I Move w-$[new_x]p w-$[new_y]p
I State 1 True
I UnSetEnv new_x
I UnSetEnv new_y[/code]
Last but not least put in your StartFunction[code]DestroyFunc StartFunction
AddToFunc StartFunction
I Module FvwmEvent FvwmEventMoveEvince[/code]
That’s it. Hope it works in your system.
Wow, that’s genius! Your solution works perfectly fine here. I guess I got the basic idea behind that tricky and complex workaround but there’s no chance I could have done that myself. It’s amazing what Fvwm is capable of. Thank you soooo much for all the effort you put into that and for this cool solution!
