Subject: Re: FVWM: Application resizing failure

From: John Latham <[email-masked]>
Date: Tue, 20 Aug 2002 16:13:28 +0100

> From: Dominik Vogt <[email-masked]>
> 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.

Out of interest, what is the easiest way to monitor the window manager
requests made by a single application?

> Bye
> Dominik ^_^  ^_^

Best wishes, John Latham

Here is the program. Press ``DoIt'', and it should collapse, then expand with
a black text area, then expand more with a white text area. On FVWM 2.4 it
ends up staying small, and you have to press ``Resize'' to make it get the
right size.

-----------------------------
#! /usr/bin/perl -w

use strict;
use Tk;

#my $Pause = 1;
my $Pause = 0;

my $Window = MainWindow -> new;

my $Text;

my $DoItButton = $Window -> Button(-text => "Do it!") -> pack();

$DoItButton -> configure
(
  -command
  => sub
     {
       sleep $Pause;
       $Text -> destroy if Exists $Text;
       sleep $Pause;
       $Text
         = $Window
           -> Scrolled("Text", -scrollbars => 'osow',
                       -background => "black",
                       -foreground => "white",
                       -width => 40,
                       -height => 4)
           -> pack(-fill => 'both', "-expand" => 1);
       $Window -> update();
       sleep $Pause;
       $Text -> destroy;
       sleep $Pause;
       $Text
         = $Window
           -> Scrolled("Text", -scrollbars => 'osow',
                       -background => "white",
                       -foreground => "black");
       sleep $Pause;
       $Text -> configure(-width => 80, -height => 10);
       $Text -> pack(-fill => 'both', "-expand" => 1);
     }
);

my $ResizeButton = $Window -> Button(-text => "Resize") -> pack();
$ResizeButton  -> configure
(
  -command
  => sub
     {
       $Window -> geometry(""); 
     }
);

MainLoop();
--
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-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 20 Aug 2002 19:54:55 +0200

> 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.

> requests made by a single application?

Put debug statements in the code (HandleConfigureRequest function
in events.c).

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], 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-masked].
To report problems, send mail to [email-masked].