On Tue, Aug 20, 2002 at 04:13:28PM +0100, John Latham wrote: > > From: Dominik Vogt <[EMAIL PROTECTED]> > > Date: Tue, 13 Aug 2002 00:42:35 +0200 > > > On Mon, Aug 12, 2002 at 06:34:27PM +0100, John Latham wrote: > > > I have a certain application, written in Perl/Tk, which does not work > > > properly > > > with 2.4.6 or 2.4.8; but did work okay with 2.2.4 and previous, and *does* > > > work okay with 2.5.2. > > > > > > The problem: when a certain button is pressed in a Perl/Tk window: > > > a text box is removed from the window > > > then a new one is added > > > then some text inserted into this new text box > > > then the text box is removed > > > then another new one is added > > > then some text is inserted into this third text box > > > then the size of the third text box is set > > > Um, I don't see where this involves any resizing. > > Sorry for not making it clearer. The resizes happen as the window gets > repacked, so most steps above cause an overall size change. > > > > Out of context this sounds like a crazy thing to want, but trust me it is > > > sensible (the window is running a command for the user, first discarding > > > the > > > old output, then showing standard error during the run, then standard > > > output > > > after finishing, and resizing to suit the new output text right at the > > > end). > > > > > > This results in several window resizes, and on 2.4.6 and 2.4.8 the > > > geometry > > > ends up wrong. Either it ends up being the smallest that was asked for > > > (i.e. > > > without the text box) or correct in width but smallest in height! The > > > resizes > > > can happen quite quickly, but I have tried adding in 2 seconds sleeps > > > between > > > each stage, and it makes no difference. > > > I can't say anything good about it without seeing the > > configuration requests from the application. > > > > I could try to write a minimal example program if that would help. > > > Please do. > > I have managed to make a small program that consistently fails on 2.4, for me, > but works okay on 2.2 and 2.5 -- attached. > > > > As I said it works okay again in 2.5.2, but I guessed it might be an > > > unknown > > > bug that has been accidentally fixed, on the grounds that you would have > > > wanted to fix it in 2.4.8 too. True? > > > Sounds like a good candidate to be fixed in Tk. Fvwm usually just > > does what the application requests in exactly that order. For > > example, I have a similar problem with xemacs since 2.3.x, but > > fvwm is really doing everything right. Instead, xemacs chokes on > > its own events. It's timing dependent. > > I can imagine it is timing dependent here too. I have tried sleeps of various > sizes between the main steps, but it makes no difference. So, if it is timing, > it must be within the (Perl)Tk functions. I have tried it on a PIII 800 and a > K6-2 500, with the same effects.
I see that funny behaviour. The application simply requests the small size and never asks for anything else, so what fvwm-2.4 is doing is right. Under 2.5, the application requests the large size after shrinking and gets exactly this. I do not have the faintest idea why the application behaves differently with the two versions. I'm not surprised either because there have been a number of similar reports where tk behaves funny. > Out of interest, what is the easiest way to monitor the window manager > requests made by a single application? Put debug statements in the code (HandleConfigureRequest function in events.c). Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at <URL: http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
