On Wed, 6 Aug 2008, Dan Espen wrote:
"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?
The data is a part of a _NET_MOVERESIZE_WINDOW ewmh request and it does
not map directly to the value_maske, but fvwm's ewmh code assumes it does.
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2506756:
The low byte of data.l[0] contains the gravity to use; it may contain
any value allowed for the WM_SIZE_HINTS.win_gravity property: NorthWest
(1), North (2), NorthEast (3), West (4), Center (5), East (6), SouthWest (7),
South (8), SouthEast (9) and Static (10). A gravity of 0 indicates that
the Window Manager should use the gravity specified in
WM_SIZE_HINTS.win_gravity. The bits 8 to 11 indicate the presence of x,
y, width and height. The bits 12 to 15 indicate the source (see the
section called Source indication in requests), so 0001 indicates the
application and 0010 indicates a Pager or a Taskbar. The remaining bits
should be set to zero.
...
Window Managers should treat a _NET_MOVERESIZE_WINDOW message exactly
like a ConfigureRequest (in particular, adhering to the ICCCM rules
about synthetic ConfigureNotify events), except that they should use the
gravity specified in the message.
This is not what fvwm does, but fvwm translates the message to a configure
request, using the data.l[0] as value_mask unchanged (ewmh_events.c:218)
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.
Yes, that is right for configure requests. The error is in the ewmh code.
/Viktor
