On Mon 24 Sep 2018 at 14:26:48 (+0200), Nicolas George wrote: > David Wright (2018-09-22): > > (Actually .xsession here.) That may well be, and it does work to get > > the xterms placed on the correct positions, but it also has downsides > > which I can avoid while xtoolwait continues to work (even with its > > bug). > > > > 1) The xterms' arguments, and (for some of them) the commands they run, > > are computed in the shell script that is ~/.xsession. While some of > > these might be simple to perform in fvwm-ese, not all of them are, > > and I'm not particularly well versed in fvwm-ese. I'm reasonably > > competent in bash dialect shell-ese however. > > You can call a shell script from Fvwm, of course. With a little > creativity, you can even call .xsession or .xinitrc itself and arrange > to have the same init code for environment and stuff but execute pre-WM > commands when it is truly the init script and post-WM commands > otherwise.
That sort of back and forth gets quite complicated quite quickly. Starting a WM and then starting a bunch of xterms is a procedure that shellese is suited for. Setting up 20+ pieces of code to be called from the WM for each xterm (so that WM's Waits can be placed between the calls) is crazy. Writing a shell script, but in fvwmese, is horrible. And writing a WM init.hook file in advance of starting the WM is just an extra body of code to maintain. > > 2) I get a log of all the .xsession operations in .xsession-errors, > > whereas the logging done by fvwm is almost all generated by the > > Echo commands I inserted. > > If you get Echo commands in .xsession-errors, that means Fvwm's output > is connected to it, and then all commands started by Fvwm will too. Not here (the first line is the init function call which creates 23 xterms): [fvwm][Echo]: Reading /home/david/.fvwm/init.hook Last edited 2018-09-22 [fvwm][FlocaleGetFontSet]: (-adobe-helvetica-bold-r-*-*-12-*) Missing font charsets: ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0 [fvwm][Echo]: Reading /home/david/.fvwm/post.hook Last edited 2017-04-14 [fvwm][Echo]: Reading /home/david/.fvwm/last-post.hook-wren-0 Last edited 2018-09-22 [fvwm][Echo]: none done [fvwm][Echo]: Initialised myvar to 0 [MyButtons][FlocaleGetFontSet]: (fixed) Missing font charsets: ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1 [FvwmPager][FlocaleGetFontSet]: (-*-times-medium-r-*-*-*-80-*-*-*-*-*-*) Missing font charsets: ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0 [fvwm][Echo]: Started MyBit Does fvwm have an equivalent of bash's set -x ? If it were to, would .fvwm's stderr get overwhelmed by output from every window operation and mouse-click? > > 3) There's still a race between the xterms when started from InitFunction. > > Although their placements are correct, they are mapped at their > > locations in a random order instead of deterministically. This > > randomises the PIDs and PTSs of their shells, which is less > > convenient for seeing who's running what at a glance. > > You may need to enforce the order with your favorite tool, but starting > from Fvwm's InitFunction will reduce concurrency and therefore make > things slightly more efficient. And I believe Fvwm is capable of doing > the wait itself, which would be even more efficient. It can indeed. Inserting a Wait after each xterm does the job and tests on my slowest machine (to make timing things easier) shows that it saves 1–2 seconds in 38; just not worth the trouble. > Also, relying on the numbers of PIDs and PTYs is really not reliable, > irregardless of how you start your xterms. No reliance, just convenience. > (Also, I had to wonder for a few seconds about why your xterms have > Presentation Time Stamps, but that is just because I have spent a > significant part of the week-end surrounded by multimedia jargon.) Yes, for some reason ps ax (or -ef) calls them pts rather than pty. Cheers, David.