Delay in moving certain windows

heya gents, ladies

lemmi start by saying i’m new to fvwm. I’m tryin gto setup a config, almost there, just tweaking out config and desktop layout now. Got one question, when i try to move windows like BPM or gkrellm there is a delay before the window actually moves of about 5 seconds, I click move… keep holding the mouse then it kicks in.

Anyone know howto fix this?


Have a look at “ClickTime” and lowering its value.

– Thomas Adam

thanks for the reply Tom, didn’t do the trick though however I dont mind at this point. I first thought something was wrong in my config and I’d come across other apps that would behave this way but since i’ve been using fvwm for about a few days it seems to be only gkrellm and bmp/xmms that behaves this way, two apps I dont move much anyway.


I’m having one of those days. :slight_smile: I didn’t mean ‘clicktime’ at all, what I really meant to say was look at: “MoveThreshold” – that’s the delay that’s used to determine whether a window is being moved or not.

Oh, and I prefer ‘Thomas’, and not ‘Tom’. :slight_smile:

– Thomas Adam

Hey its sunday, i’ll let that one slip :smiley:

I actually tried MoveThreshold before coming here, that also didn’t work. Might be some kinda thing with with fvwm and apps that normally dont want to use WM decoractions.

Thanks again though Thomas :slight_smile:

Indeed, it’s a known xmms bug even though it doesn’t always show up. I for one don’t have trouble with it at the moment, though I did in the past, so it might be related to xmms’ version or such (using 1.2.10 atm, though it might be that gentoo applies certain patches, I’m not sure about that…)

I’m having it with;
xmms 1.2.10 ( beep media player 0.9.7 also)
gkrellm 2.2.7

it’s probably not gentoo related …

i have here a slackware based box, and i have the same prob with gkrellm 2.2.4 - i also had bmp some time ago and there was this move-delay too. but xmms 1.2.10 behaves pretty normal…

maybe a gtk2 related issue?

aye, same here, running

slackware 10.1
gtk2 2.6.8
xorg x 6.8.2 (patched with gentoo’s transparent menus patch)

Is this the bug where you click on the xmms-provided titlebar to move it and it lags behind? The fvwm-provided titlebar moves it the way it’s supposed to for me… but that looks ugly.

If you have a key binding (such as alt+left-mouse when clicked on FST or W) you wont get the lag and the window manager will actually take care of moving the window instead of the buggy way the application does.

It’s probably an xmms bug indeed…some people (dare I say “most people”) have it, some others don’t…

yep, this is the case, with fvwm decorations it moves ok, however as for it being a bug specific in/to xmms (also beep media player) I’m not sure as i have the problem with gkrellm also but again using fvwm decorations i’m able to move it just fine.

That’s probably because xmms and gkrellm use the same kind of ugly hack to get rid of the wm decors and take control of movement themselves…

This is another nice thread to advertise the marvellous gqmpeg, which you can find here:
It uses the mpg123 command line program for mp3 play, or alternatively mpg321.

ok the admin moved me into this thread from here: viewtopic.php?p=7048

on the subject of audacious and the other xmms forks which decorate themselves and cause window movement difficulty in fvwm (2.5.16):

these players create child windows, such as “audacious playlist editor” and “audacious equalizer”, that can stick to any edge of the main application window. when you move the main app, these child windows “go along for the ride.” i understand that using fvwm, you can implement mouse or key binding to move the windows “normally” but —

is there any way to have these child windows, if they exist, move along with the main window and retain their “adhesion” to the edge of the main app?

i should add that moving the main app now DOES take the child windows along to their new location – the issue is that you get no visual tracking feedback, i.e. you only see the move once you release the mouse button and all the windows shift instantly to their new location.

Umm, not easily. You would have to do it post-move anyway, since you can
only move one window at a time. You’d then have to calculate the relative
move amount and shuffle the windows up by that amount.

If I get time I might look into it later on. Other than that, you’ll have
to either do it manually, or just don’t move the main window. :stuck_out_tongue:

– Thomas Adam

ok, i’ll leave it at that. thanks for your reply.


I had this problem for a too long time now , and i finally found that a single

Mouse (audacious) 1 W A pick move

did the trick, hurra ! :smiley:

Edit: … but you will have problems with transient windows :cry:
so bind it to another mouse button.