KDE applications disappear on fvwm restart

Hi All,

I noticed the following strange behaviour: I am running fvwm as my window manager (no KDE / Gnome / crap). I started Kuickshow, which ran fine etc. However when I restarted fvwm, the Kuickshow window dissapeared.

pgrep kuickshow showed that kuickshow was still running. I did not get any error messages at the controling terminal. I could not however find kuickshow on any desktop, or listed by windowlist. I can reproduce this error everytime.

Also (possibly unrelated), my FvwmPager module coredumps on most restarts. Once it core dumps, I get a black (sometimes ugly) rectangle on the top right corner of my screen. On issuing killmodule FvwmPager and module FvwmPager, it starts right back up and everything works fine. Strangely when I log in for the first time (i.e. on startup), my pager loads fine. My RestartFunction is empty. I have no idea if this is in any way related to my Kuickshow window dissapearing though.

Any ideas? Can anyone else reproduce these bugs? Im running Gentoo 2.6.11, Fvwm 2.5.12, Xorg 6.8.2. Possibly irrelevant I’m running an AMD K6-2 (stone age) :slight_smile:




Could it be that the window has been raised over all others, and moved off the viewport in an odd location? Next time this happens, open up FvwmConsole, and try the following command:

All (CurrentDesk, !Transient, AcceptsFocus) ThisWindow ("Kuickshow") WarpToWindow

Does that warp the viewport to the window’s location?

Possibly related. When it next coredumps, could you post it on the internet for me to download and analyse?

– Thomas Adam

I doubt this. The first few times it happened, I fired up a FvwmConsole and executed


No Kuickshow window was listed, and I had to kill the process from commandline. I will try what you suggested, and let you know if something different happens.

Sure. The pager coredump is a little more unpredictable than the Kuickshow dissapearing though. 99% of the time (on fvwm restart) my pager does not start properly. However sometimes just hangs, and does not coredump. Hopefully I can convince the pager to coredump, and send you the file. (It should be the file called “core” in my home directory right?)

Will get back to you tonight (when I get home to my Gentoo machine).


Yup, it should be. Or it might core dump from the CWD of fvwm (unlikely). You’ll have to ensure that coredumps are allowed. The bash shell tends to turn such things off. So before you launch fvwm (perhaps in your ~/.xsession file), add:

ulimit -c 3708

Which should be of a sufficient size to dump the core file.


– Thomas Adam.

First, in relation to the Kuickshow problem, you were right Thomas. On executing WarpToWindow, my Kuickshow window was raised. I’ve found on restarts the KuickShow window moves one page down, and one page right, and eventually disappears from your visible desktop. Don’t know if that’s an fvwm issue or a KDE issue (maybe KDE folks number the pages starting from 1).

But now that I can get my window back, it’s not so serious :slight_smile:

Finally about the FvwmPager coredump – No luck sorry. It hangs every time I restart, but for some reason does not coredump (I recall seeing a coredump only twice so far. Since I’m in the process of writing my config, I can’t remember the settings I had when the pager core dumped).

I managed to trace the Crash on restart to a problem with RootTransparency and tinting. I used the following for my fvwm config file:

DestroyFunc StartFunction
AddToFunc StartFunction

  • I exec fvwm-root --retain-pixmap ~/etc/wallpapers/png/smaug.png
  • I Module FvwmConsole
  • I Module FvwmPager

Key r A S4 Restart

setenv TintedLight 16
setenv TintedDark 17
setenv TintedActive 18

Colorset 15 fg #1f1f1f, bg #000000, RootTransparent
Colorset $[TintedLight] fg #808080, RootTransparent, Tint #004040 50
Colorset $[TintedDark] fg #808080, RootTransparent, Tint #010101 50
Colorset $[TintedActive] fg #808080, RootTransparent, Tint #202040 75

DestroyModuleConfig *
*FvwmPager: Colorset * 15
*FvwmPager: Geometry 200x150-10+0

*FvwmPager: SloppyFocus

*FvwmPager: MiniIcons
*FvwmPager: UseSkipList

*FvwmPager: NoDeskHilight

*FvwmPager: Hilight #ccccff

*FvwmPager: WindowColors #cccccc #777799 #ffffff #9999cc

*FvwmPager: Font none
*FvwmPager: SmallFont xft:Bitstream Vera Sans:Regular:Roman:size=6
*FvwmPager: Balloons All
*FvwmPager: BalloonBack Yellow
*FvwmPager: BalloonFore Black
*FvwmPager: BalloonFont xft:Bitstream Vera Sans:Regular:Roman:size=10
*FvwmPager: BalloonYOffset +2
*FvwmPager: BalloonBorderWidth 1
*FvwmPager: BalloonBorderColor Black
*FvwmPager: BalloonStringFormat “%t”
*FvwmPager: HilightColorset * $[TintedLight]
*FvwmPager: WindowColorsets $[TintedDark] $[TintedActive][/code]
If I comment out the Tinted colorset commands, then the restart is extreemly quick, and there is no trouble at all with the pager. However when I use the Tinted colorsets, the pager crashes on restart almost every time. (It crashes every time I press alt-tab right after the restart, and it crashes sometimes when I do nothing on a restart)

Beats me. If you know what’s going on, I’d be very appriciative. I’ve unlimited the core dump size, so if I ever get a core dump I’ll send it right along :slight_smile:



I’m unsure. It’s more likely some sort of EWMH thing. Setting the following as the first line in your ~/.fvwm2rc file might help:

BugOpts ExplainWindowPlacement

Then, assuming fvwm logs to ~/.xsession-errors, on restart, or what have you, if the window is replaced, Fvwm will log it there. It might prove useful.

However, that’s just being over pedantic on my part, most likely. KDE apps have always had a history of raising windows at odd times. Indeed, the following should fix this issue once and for all:

BugOpts RaisedOverUnmanaged On

That’s a good approach. If anything, I’d be inclined to take a minimal config, with nothing more than just a pager definition, and build it up – you can use Xnest to do this if you want to retain your current running Fvwm instance; rather than having to restart it each time.

This is what I’d have hoped for with Transparency (both with ‘RootTransparent’ and ‘ParentalRelativity’ as you have it.

[…snip pager definition…]

That looks OK to me. I don’t actually use transparency, mind.

Tinted colorsets are notorious for this sort of thing. From what I know about tinting, there has never been any guarantee that it would work well with colorset; the preferred definition is just to use ParentalRelativity, and leave them alone, if they’re problematic for you.

Please do.

– Thomas Adam

I generally start another X session (startx – :1), and then repeatedly restart fvwm :slight_smile:. I haven’t figured out how to use Xnest yet …

But to get back on topic, after a good few hours of “urging” the pager to core dump, I’ve had no luck. The problem is that I was coping my config file from 3 / 4 different sources (fvwm-crystal, fvwm95, and two randomly downloaded ones). I tried a few combinations, but can’t for the life of me remember the combination I had when the page used to coredump :slight_smile:.

So you might not be getting your coredump Thomas … :frowning:

Will try the suggestions about the KDE windows when I get home. Thanks :slight_smile:


Yup, switching VTs is a valid approach. I like Xnest, as it allows me to be lazy in that regard. :slight_smile:

That’s not such a bad sign, though – if you have to try and get it to crash, it’s obviously unlikely to. :slight_smile: There’s no rush for the coredump, just an as-and-when.

You’re welcome.

– Thomas Adam