"Johnny Ljunggren" <[EMAIL PROTECTED]> writes: > Hello > > >>> First detach a toolbar and move it somewhere on the screen. Then > >>> release and select again and try to move left or right. The > >>> position is locked sideways, but can be moved vertically. > >> Is there some way to pay one of the Fvwm developers to look at this, > or > >> could you point me to roughly where in the code this is handled? > > this is from the Fvwm source file fvwm/events.c > > At least part of the Qt logic is in file: > > qt-x11-opensource-src-4.3.5/src/gui/widgets/qtoolbar.cpp > I've dug with a big shovel into this and have come up with this: > The 'fault' on the fvwm side is in the method > __handle_cr_on_client(...) (events.c) where the cre.value_mask never > has the CWX bit set. For test purposes I did: > cre.value_mask |= CWX; > and then it works as it should. To figure out why CWX was never set I > looked in the qt source code and found in file qwidget_x11.cpp, method > setGeometry_sys(...): > e.xclient.data.l[0] = StaticGravity | 1<<8 | 1<<9 | 1<<10 | 1<<11 | > 1<<12; > The first four bits are set to StaticGravity=1010b which will match CWY > (10b) but not CWX (01b).
I'm not sure I follow this part. How does value_mask match to data? > I'm not an expert on this but it seems to me that it is not correct to > check for CWX/CWY at all. I found some links but don't have enough X > knowledge to interpret either way: > [1]http://standards.freedesktop.org/wm-spec/1.4/ar01s09.html > [2]http://tronche.com/gui/x/xlib/window/attributes/gravity.html > What side effects would it have to remove the check for CWX/CWY in this > method? Cool, I did some poking around but didn't get that far. Fvwm is examining the configure request to see if it's a request to move the window. Fvwm says if X/Y isn't being changed, the window isn't being moved. That seems right to me. > BTW: Style * MWMDecor overrode the DecorateTransient style, so that's > why I was a bit lost... Interesting.
