> From: Dominik Vogt <[EMAIL PROTECTED]> > Date: Mon, 12 Aug 2002 23:21:38 +0200
> On Mon, Aug 12, 2002 at 06:24:58PM +0100, John Latham wrote: > > This is not actually an undocumented feature change, but it is understated! > > :-) > > > > Fvwm 2.2.4 man page says: ``Fvwm remains fully functional during a wait.'' > > > > Fvwm 2.4.8 man page says ``Fvwm remains partially functional during a > > wait.'' > It's just a better description of what actually happens. The Wait > command itself was not changed in any relevant way. > > I spotted the one word difference after a few hours tracking down the cause > > of > > a very strange behaviour. Presumeably, you have optimised away some threads > > that had a memory/CPU overhead, and perhaps never imagined anybody would be > > using Wait in a clever (=stupid!) way. > > > > Alas, in AnotherLevelUp I was using Wait in a multi-threaded way, > There is no multi threading in fvwm. > > waiting for > > an effect from a form which prompts the user to save his/her current > > preferences, if they have been changed since last saved; when he/she asks > > for > > a new set of preferences to be loaded. So we had a Wait active at the same > > time as a form that needed user interaction. In 2.4 this does not work as > > all > > the window events seem to be disabled during a Wait, all mouse clicks act on > > the root window only. > Event processing continues as usual. The modules can receive and > send data to and from fvwm, but fvwm ignores all module input > until the wait finishes. As this was the same in 2.2.x, I'm not > sure what was changed. In general: Wait + using modules = bad. This was indeed a Red Herring. I now understand why this stopped working! It's that BusyCursor thing yet again: during the Wait, FVWM was holding the mouse, so the user could not click on the FvwmForm buttons, which were the trigger for ending the Wait. And I had not set BusyCursor Wait on, sugesting that FVWM always grabs the mouse for a Wait too, regardless of BusyCursor Wait on/off. The multi threading `feel' I had was coming from the FvwmForm process running in parallel to FVWM, so one could say the `whole thing' is multi threaded, but the mouse grabs now make the UI single threaded. > > It probably serves me right! I have rewritten it to work in a different, and > > single threaded, way. > Good idea. TH Wait command is really just meant to wait for a > window that appears quickly. Any other use is asking for trouble. > You can easily achieve the same benefits with FvwmEvent, but > without the bad side effects. My new approach is much more reliable anyway. I seem to remember being unhappy with the old approach, but needed to do it that way because I didn't realise one could generate FvwmForm configurations dynamically (e.g. PipeRead) at the time I first wrote it. > > Is it worth writing some hints in the man page indicating what sort of > > things > > do not work during a Wait -- or am I likely to be the only person daft > > enough > > to try abusing Wait in this way? :-) > I'll add something. Thank you. BTW, I have just spotted another ``fully functional'' phrase that you might like to edit, at least it is still present in the 2.5.2 man page, in the BusyCursor section. > Bye > Dominik ^_^ ^_^ Best wishes, John Latham -- 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 [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
