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.
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. 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.
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.
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 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…
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.
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.
This is another nice thread to advertise the marvellous gqmpeg, which you can find here: gqmpeg.sourceforge.net/
It uses the mpg123 command line program for mp3 play, or alternatively mpg321.
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. :P