On Tue, 4 Oct 2005, Yusuf M Motara wrote:
On Mon, 03 Oct 2005 @ 09:04:46, Viktor Griph wrote:
[...]
This sounds very similar to a problem with resizing shaded windows that is
fixed in the CVS. It's very possible that the fix for that also solves
this. Can you test with the CVS snapshot of October 2 and see if this
error still exists? If not, can you test it out with 2.5.15 once released?
[...]
I am now running the same config with the October 2 CVS, and the problem
is still there. It can be artificially created by temporarily taking a
network interface down, then putting it up again (all whilst gkrellm2 is
in a West-shaded, untitled state), then unshading the gkrellm2; this
procedure (assuming that gkrellm2 is set to show active interfaces...)
results in gkrellm2 resizing itself whilst shaded, and provokes the
problem mentioned (a 1-px sliver of gkrellm being visible, the rest
being transparent).
Can anyone else reproduce this problem using the above steps? If not,
given a few days, perhaps I can produce a sample config that will
demonstrate it...
Yes, I've been able to reproduce it. I've also done some debuging, but not
mush. Don't have the time to dig that deep in the code right now. What
I've found is:
gkrellm2 resizes itself with application requests. These are not handled
correclty by fvwm for shaded windows. However, I'm not sure what correctly
is. By just updating unshaded geometry info it would work as any other
shaded resize, but gkrellm2 doesn't like this either (it will need to
have the client window resized as well, even thou it is hidden, or it
will not request for another sizec hange to the old size, and will still
draw as if it had the old size).
By also resizing the client window the bug goes away for shading in the
title direction, but still stays on other directions. I've not yet found
out why.
What is the correct way for fvwm to deal with app requests for resizing of
shaded windows?
/Viktor
