On Tue, Aug 20, 2002 at 04:13:28PM +0100, John Latham wrote:
> > From: Dominik Vogt <dominik.vogt_at_gmx.de>
> > 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: dominik.vogt_at_schlund.de, 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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue Aug 20 2002 - 12:55:41 BST