>>>>> "Paul" == Paul Lange <pel_at_ece.utexas.edu> writes:
Paul> Hello all.
Paul> In my .fvwmrc, I run FvwmCpp on several files. A file for
Paul> styles, one for functions, one for menus, one for modules, one
Paul> for keymaps, yadda yadda yadda. However, if I add to the
Paul> InitFunction in one of these files, the new InitFunction never
Paul> gets ran unless I open an FvwmTalk and execute myself or bind it
Paul> to a key or button. Even if I try and simply call the function
Paul> as the last thing in my .fvwmrc, it still does not get executed.
Paul> What am I doing wrong here?
Paul> Here is a copy of my .fvwmrc where I read in the separate files,
Paul> if this helps.
....
Paul> I add to my InitFunction with the read from FvwmCpp of
Paul> PelFunctions.
Paul> If anybody could give me some pointers as to how to get that
Paul> thing going, I would be most grateful.
Various problems with using the FvwmM4 & FvwmCpp modules have always
existed, with the two most prevalent being:
- rc defaults not taking effect on windows that were in
existence before fvwm started
- startup functions not being executed.
I have yet to really be able to really reproduce the first. But I
just tried a quick test with the second (your problem) and after
adding some more debugging statements to the code I was able to
reproduce it and see what the problem actually is a little better as
well.
The two behaviors are most likely related to the same underlying
problem. What's happening is this: fvwm is set up to run the startup
stuff (capturing all the windows, building the menus, and running the
startup func), after the first initial read command is finished.
That way theoretically all stuff should get processed before the init
func is called.
But unfortunately since FvwmCpp/M4 is a module which is sending back a
Read command and module input doesn't get processed until fvwm hits
the main event loop, fvwm doesn't see the cmd to do the reading of the
output of FvwmCpp until after it is done with the initial read of your
..fvwm2rc file, so the startup stuff has already been run.
I'm trying to think of a good/correct solution to this right now, but
haven't got it yet, and don't have a lot of time to devote to it right
now.
One idea I had previously was to change FvwmM4/Cpp to be standalone
scripts or executables that could be run & read via the new PipeRead
command, which should eliminate both these problems entirely and have
the added benefit of being able to run them standalone so you can
visually check the output easier. But, I think I ran into some small
problems with this idea (don't recall right now).
Well, I have to get back to some pressing problems here at work. I'll
look into this problem more later if I get a chance, but I doubt I'll
be able to get anything for it into 2.0.44 (which I'd like to get out
later today or tommorrow). Perhaps for 2.1.0 would be a more
realistic goal.
Chuck
*******************************************************************************
Charles K. Hines <chuck_hines_at_vnet.ibm.com>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]
"Go back to sleep, Chuck. You're just havin' a nightmare
-- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
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 Wed Jan 15 1997 - 08:55:18 GMT