I have a problem redefining FVWM internal function to do some additional task.
For example, I want to redefine Iconify function to clear state 17 from a window. I do:
DestroyFunc FvwmIconify
AddToFunc FvwmIconify
+ "I" All (State 17) State 17 False
+ "I" Iconify
, then I use FvwmIconify where it’s appropriate.
It works fine and as I expect it to, but now FVWM misbehaves. Instead of silently iconifying window, it turns shortly X cursor into XC_dot and when I hold a mouse button I hear silent hiss coming directly from my hardware . During hiss, FVWM tops 25% CPU. When I just press Iconify button on a window, the same sequence appears: cursor turns into XC_dot, then short hiss, then cursor go back to normal, and then window is iconified.
Without overriding function, i.e. just using Iconify, when I hold a mouse button on a window Iconify button, there is no hiss and cursor stays the same. And no CPU eat up at all.
This also happens with every custom defined function, which somehow is linked to window controls.
I also do not see where FVWM turns the cursor into XC_dot, even source code does not contain an XC_dot in it’s defaults.
This happens with both FVWM 2.6.5 and 2.6.7. I wish I would to get rid of this annoying hiss and cursor messing and get custom functions back to what FVWM does when internal function is executed, but I do not know where to start.
Hallo, wild cat,
every time this function is called FVWM removes the State-17 bit from “All” existing windows. These might be very many.
Was this really your intention? Didn’t you just want to clear the bit from the “Current” window?
Event though FVWM modifies only one integer value for every window, there might be considerable overhead, so I can understand the CPU load.
Well I forgot to explain why I need that, but I thought it is generic.
I use this to mark all windows which are needed to be restored when I mass iconify them with Super+D (Win+D).
When I press the key sequence, another function responsible for that marks all current normal windows with State 17.
The function I posted however is intended to clear this mark if a state was modified for some reason, i.e. one or more of State 17 windows were reactivated (it means that new window list of normal windows is started, so forget about old one), so there will be no mess if I will press Super+D again.
Marking functions work fast, I proved that with FvwmCommand.
And yes, it’s as intended. I do remove State 17 from all windows I am interested in. But no, even with one window it’s a constant problem.
This happens if I will just redefine it a-la:
same behavior. I press Iconify, short hiss from hardware, cursor flicks to XC_dot and back, and function is performed.
I I hold Iconify button, hiss is clear, cursor is changed into XC_dot and stays such until I release mouse button. Both cases take 25% CPU load.
If I do not redefine function, it behaves back as normal. Both when I just click button or hold it. And no CPU load.
I will try to look into code more closely next week and run it through debugger or printfs to see what’s really there.
Manual page lists WAIT as XC_watch, which is replaced by XC_dot on my system…
I did reset it to left_ptr with
CursorStyle WAIT left_ptr
, and cursor problem gone.
2. Silent hiss is due to very fast looping in WaitForButtonsUp when a custom function immediately returns.
I had to slow down it a bit with
usleep(1000);
inserted just into beginning of a loop, and at least that nasty hiss gone away, and fvwm is nearly at idle in such times.
I am not competent in fvwm code so this is a hack to make me happy. If someone has a better solution, I will be happy to hear it of course!
