Hi,
I just upgraded 2 machines to 2.0.40 and found that my m4 style .fvwmrc
files failed to work correctly. The basic problem is that certain
options/styles fail to get set. It also appears to be pseudo-random in
nature, 3 different starts have 3 different results.
Setting DBUG in configure.h I observed that fvwm starts FvwmM4 and then goes
on to do various X11 initializations, finally entering it's HandleEvents loop.
By the time FvwmM4/m4 have processed .fvwm2rc into /tmp/fvwmrcxxxxxx and
returned the SendInfo( "read /tmp/fvwmrcxxxx" ) message MANY X events have
been handled. I am not an X11 programer, so I have NO idea where the exact
problem is. My first observation was that placing a "sleep 15" into .xinitrc
immediately after starting fvwm2rc would fix the problem (usually). So I went
fishing for a way to syncronize fvwm2 and FvwmM4. The result is the following
set of patches to fvwm/fvwm.c:
------------------------------------- cut -------------------------------------
-
*** fvwm/fvwm.c 1996/02/12 06:34:38 1.1
--- fvwm/fvwm.c 1996/02/12 23:49:47
***************
*** 103,108 ****
--- 103,180 ----
int fd_width, x_fd;
char *display_name = NULL;
+ #define M4_RACE
+ #if defined( M4_RACE )
+
+ int raceSync = False;
+
+ /***************************************************************************
+ *
+ * Bogon alert!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+ * major hack to sync FvwmM4 pre-processor
+ * this routine was hacked from events.c: My_XNextEvent()
+ * may or may not work with FvwmCpp
+ *
+ * Wait for configuration by pre-processor to complete.
+ *
+ ****************************************************************************
/
+ int M4OutputReady( void )
+ {
+ extern int fd_width;
+ fd_set in_fdset;
+ Window targetWindow;
+ int i,count;
+ int retval;
+
+ DBUG("M4OutputReady","Entered");
+
+ FD_ZERO(&in_fdset);
+ for(i=0; i<npipes; i++)
+ {
+ if(readPipes[i]>=0)
+ {
+ FD_SET(readPipes[i], &in_fdset);
+ }
+ }
+
+ #ifdef __hpux
+ retval = select( fd_width, (int *)&in_fdset, 0, 0, NULL );
+ #else
+ retval = select( fd_width, &in_fdset, 0, 0, NULL );
+ #endif
+
+ /* Check for module input. */
+ for(i=0;i<npipes;i++)
+ {
+ if(readPipes[i] >= 0)
+ {
+ if((retval>0)&&(FD_ISSET(readPipes[i], &in_fdset)))
+ {
+ if((count =
+ read(readPipes[i],&targetWindow, sizeof(Window))) >0)
+ {
+ DBUG("M4OutputReady","calling HandleModuleInput");
+ /**
+ * we blindly assume it is the "read /tmp/xxx" message
+ * from FvwmM4 or FvwmCpp
+ */
+ HandleModuleInput(targetWindow,i);
+ return True;
+ }
+ if(count <= 0)
+ {
+ DBUG("M4OutputReady","calling KillModule");
+ KillModule(i,10);
+ }
+ }
+ }
+ }
+ DBUG("M4OutputReady","Leaving");
+ return False;
+ }
+ #endif /* M4_RACE */
+
+
/***********************************************************************
*
* Procedure:
***************
*** 347,352 ****
--- 419,442 ----
ExecuteFunction(config_command, NULL,&Event,C_ROOT,-1);
DBUG("main","Done running config_command");
+ #if defined( M4_RACE )
+ if ( (mystrncasecmp( config_command, "FvwmM4", 6 ) == 0)
+ || (mystrncasecmp( config_command, "FvwmCpp", 7 ) == 0) )
+ {
+ raceSync = True;
+ }
+ # if 0
+ /**
+ * something not ready for reading m4 processed config file yet,
+ * if we do it now 'Scroll' functionality is hosed.
+ */
+ if ( raceSync )
+ {
+ while ( M4OutputReady() != True ) /** spin */;
+ }
+ # endif /* 0 */
+ #endif /* M4_RACE */
+
if(Scr.d_depth<2)
{
Scr.gray_pixmap =
***************
*** 425,430 ****
--- 515,532 ----
#endif
XUngrabServer(dpy);
UnBlackoutScreen();
+
+ #if defined( M4_RACE )
+ /**
+ * WE MUST WAIT for FvwmM4 to finish building file, then "read file"
+ * BEFORE we can start handling X events
+ */
+ if ( raceSync )
+ {
+ while ( M4OutputReady() != True ) /** spin */;
+ }
+ #endif /* M4_RACE */
+
DBUG("main","Entering HandleEvents loop...");
HandleEvents();
DBUG("main","Back from HandleEvents loop? Exitting...");
------------------------------------- cut -------------------------------------
-
I also found a bug in FvwmM4 itself, if you don't set '-debug' when invoking
fvwm2rc, FvwmM4 removes /tmp/fvwmrcxxxxxx when it finishes. This means that
any
modules started interactively (eg. via pulldown menues) are given the now non-
existant file's name as it's expected config file.
------------------------------------- cut -------------------------------------
-
*** modules/FvwmM4/FvwmM4.c 1996/02/12 06:32:53 1.1
--- modules/FvwmM4/FvwmM4.c 1996/02/12 23:04:33
***************
*** 181,191 ****
--- 181,196 ----
/* For a debugging version, we may wish to omit this part. */
/* I'll let some m4 advocates clean this up */
+ #if defined( M4_ERASE )
+ /**
+ * won't this remove the file used by various modules???
+ */
if(!m4_debug)
{
sprintf(delete_string,"exec rm %s\n",tmp_file);
SendInfo(fd,delete_string,0);
}
+ #endif /* M4_ERASE */
}
------------------------------------- cut -------------------------------------
-
Both of these will install from the top level directory via:
% patch -p < patch-aa; patch -p < patch-ab
Note that the first patch to fvwm.c is quite GROSS, but it does work. Perhaps
it will create insite for a more X literate programmer to find a correct
solution. I have NOT attempted to use these patches with cpp, and am just
assumming that the same problem might exist. So look expecially hard at them
b4 using with FvwmCpp.
--
Steve Passe | powered by
clem_at_clem.systemsix.com | FreeBSD
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Feb 12 1996 - 19:23:38 GMT