On Wed, Oct 05, 2005 at 12:02:52AM +0200, Viktor Griph wrote: > 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. I've no idea either, but fvwm ignores any window requests to change the size or position while a window is shaded. That is because it is the only thing fvwm can do that (a) conforms to the ICCCM2 (any resize request may be ignored) and (b) does not give the application any information about its layout. (b) is important because the client window has a bogus position while it is shaded. Some applications look at the absolute position of the window while it is shaded and do strange things. Even worse, other applications (e.g. xemacs) look at the frame's size and position and resize their client window accordingly. This is definitely not something you want to happen. Note that for the above reasons fvwm does not change the size (and position?) of the client window at all when shading/unshading a window. Instead it resizes the parent window. An fvwm window has a big frame window with the decorations and the parent window. The client window is a child of the parent window. Both are exactly the same size (unless shaded). > 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? See above. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
