On Tue, Jul 24, 2001 at 11:06:26AM -0400, Terry Gliedt wrote:
> Dominik Vogt wrote:
> >
> > On Tue, Jul 24, 2001 at 09:05:54AM -0400, Terry Gliedt wrote:
> > > This goes back to a thread that is several months old where a fix was
> > > generated for the fvwm window manager to fix a slow popup dialog box in
> > > Perl/Tk apps. The fix was based on a similar problem discovered in
> > > Tcl/Tk (I don't know any of the details). I'd appreciate hearing
> > > directly from anyone who can shed some light on this. I'll post this to
> > > other groups too. TIA
> > >
> > >
> > > Has anyone else seen this?
> > >
> > >
> > > I have good circumstantial evidence that this change to fvwm2 causes
> > > some sort of problem with at least one Tcl/Tk app. This could be a
> > > problem in the application, Tcl/Tk, an incorrect fix for fvwm or even
> > > mean that Perl/Tk needs a change for the original problem.
> > >
> > > The application 'tkcvs' is a Tcl/Tk GUI interface for CVS. Most times,
> > > but not always, when one selects a file and then selects the Commit
> > > button, a window opens for the reason to be entered and then abruptly
> > > closes. CVS commit is not done. I've been using the same version of
> > > tkcvs for many months and this symptom just began showing up after we
> > > converted to Solaris 5.7.
> > >
> > > I have other TkCVS apps (like TKDIFF in the same package) that do not
> > > show this problem.
> > >
> > > It is very difficult for me to debug TCL apps, but it appears the
> > > problem occurs in a call to TKWAIT after the commit prompt window is
> > > created.
> > >
> > > Upgrading to the latest version of tkcvs makes no difference.
> > >
> > > The problem seems very consistent on both Linux and Solaris systems.
> > >
> > > Upgrading to fvwm 2.4 (where the fix has been applied) makes no
> > > difference.
> > >
> > > Removing the fix in fvwm (events.c) FIXES the TkCVS problem.
> >
> > Could you by any chance tell us *which* fix you are talking about?
>
> In events.c around line 2125 (fvwm 2.4 source) you will see
>
> cre->value_mask &= !CWStackMode;
> cre->value_mask |= (ecre->value_mask & CWStackMode);
> cre->above = ecre->above;
> cre->detail = ecre->detail;
> /* srt (28-Apr-2001): Tk needs a ConfigureNotify event after a raise,
> * otherwise it would hang for two seconds */
> new_g = Tmp_win->frame_g;
> do_send_event = True;
> }
> } /* while */
> } /* if */
>
>
> Removing the new_g and do_send_event allows TkCVS to behave, but brings
> back the Perl/Tk slow dialog problem.
Ah, yes. TkCVS maps a new window, asks the window manager to
raise it and gets a ConfigureNotify in response, can't handle it
and closes the window. While responding with a ConfigureNotify to
a Raise request is not really covered by the specs (ICCCM2), the
application should be prepared to receive a ConfigureNotify at any
time and handle it gracefully. I can't tell if this is a problem
in Tk or the application, but it should definitely be reported to
the TkCVS developers. I don't know what fvwm could do
differently other than creating a new style that allows control
over sending/not sending events. BTW, the hanging Perl/Tk dialog
boxes are also a Perl/Tk bug that should be reported. Since a
number of applications have similar problems (e.g. xemacs), the
fix should still stay in fvwm's code.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: d.vogt_at_lifebits.de
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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 Jul 24 2001 - 11:22:00 BST