colas@mirsa.inria.fr (Colas NAHABOO) (06/13/89)
From article <1238@tnoibbc.UUCP>, by remco@tnoibbc.UUCP (Remco Bruyne): > In article <1258@isieng.UUCP> pling@.UUCP (Paul Ling) writes: >>Using twm as a window manager, I always had to wait for several seconds for >>a new xterm. I don't see the same problem with uwm. > We have the same problem with twm and also with awm. We had a quick look > at it and it appeared that xterm tries to interact with the window manager > but gets no reply. After a number of seconds the request is timed out. > > We did not want to spend any time in solving this problem, but maybe > the problem is solved in the next X release. The solution to fix xterm is to add the in .Xdefaults the line: xterm.waitforwm: false And Voila! an Xterm in 2.5 sec on any reparenting WM (e.g gwm :-)). The bug in the xterm code are the lines 2075-2077 in file charproc.c in the sources of the X11R3 xterm: (void) XtMakeResizeRequest((Widget) term, (Dimension)width, (Dimension)height, &term->core.width, &term->core.height); which SHOULD be deleted (or placed elsewhere). The bug is that xterm is waiting 5 seconds for the WM to resize its window, while it didn't map it!!! Colas NAHABOO BULL Research FRANCE -- Koala Project (GWM X11 Window Manager) Internet: colas@mirsa.inria.fr Surface Mail: Colas NAHABOO, INRIA - Sophia Antipolis, 2004, route des Lucioles, 06565 Valbonne Cedex -- FRANCE Voice phone: (33) 93.65.77.71, Fax: (33) 93 65 77 66, Telex: 97 00 50 F
envbvs@epb2.lbl.gov (Brian V. Smith) (06/14/89)
In article <185@mirsa.inria.fr>, colas@mirsa.inria.fr (Colas NAHABOO) writes: From article <1238@tnoibbc.UUCP>, by remco@tnoibbc.UUCP (Remco Bruyne): > > In article <1258@isieng.UUCP> pling@.UUCP (Paul Ling) writes: > >>Using twm as a window manager, I always had to wait for several seconds for > >>a new xterm. I don't see the same problem with uwm. > > We have the same problem with twm and also with awm. We had a quick look > > at it and it appeared that xterm tries to interact with the window manager > > but gets no reply. After a number of seconds the request is timed out. > > > > We did not want to spend any time in solving this problem, but maybe > > the problem is solved in the next X release. > > The solution to fix xterm is to add the in .Xdefaults the line: > > xterm.waitforwm: false > > And Voila! an Xterm in 2.5 sec on any reparenting WM (e.g gwm :-)). > > The bug in the xterm code are the lines 2075-2077 in file charproc.c in > the sources of the X11R3 xterm: > > (void) XtMakeResizeRequest((Widget) term, > (Dimension)width, (Dimension)height, > &term->core.width, &term->core.height); > > which SHOULD be deleted (or placed elsewhere). > > The bug is that xterm is waiting 5 seconds for the WM to resize its window, > while it didn't map it!!! While this works when a window manager is running, if there is no window manager running, you get an xterm of size 1x1 (pixels). We start our xterm from /etc/ttys with the server (yes, I know that is the old way) and the window manager is not yet running, so we don't get a usable xterm at all. In gneral, I don't think it is a good idea to require that a window manager is running to have an xterm (or any other window for that matter). However, Colas' solution with the "xterm.waitforwm: false" in the .Xdefaults (or resources) file is a good workaround. _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory We don't need no signatures!
colas@mirsa.inria.fr (Colas NAHABOO) (06/15/89)
I wrote: >> The bug in the xterm code are the lines 2075-2077 in file charproc.c in >> the sources of the X11R3 xterm: ... >> which SHOULD be deleted (or placed elsewhere). Brian V. Smith (bvsmith@lbl.gov) writes: > While this works when a window manager is running, if there is no window > manager running, you get an xterm of size 1x1 (pixels). You are right... I think the best statement is made by the comments just following these bogus lines in the source of Xterm: /* XXX This is bogus. We are parsing geometries too late. This * is information that the shell widget ought to have before we get * realized, so that it can do the right thing. */ Anyways, I will surely modify gwm to handle this case, (as seems to have done Tom LaStrange with twm), but the .Xdefault trick will do the job till the R4 is out... (Bull is officially putting it in the app-defaults on its port of X)