On 21 May 2001 13:00:25 +0200, Dominik Vogt wrote: > > On Fri, May 18, 2001 at 06:01:03PM +0000, Mikhael Goikhman wrote: > > On 10 May 2001 12:35:27 +0200, Dominik Vogt wrote: > > > > > > From the ChangeLog: > > > > > > 2001-03-22 Dominik Vogt <[EMAIL PROTECTED]> > > > > > > * fvwm/functions.c (execute_complex_function): > > > fixed button presses being passed to other applications with functions > > > that only have immediate actions > > > > > > > This locked cursor behaviour is not good. Wait is mostly used in "I" > > > > functions. It is used in many places, including fvwm-themes, FVWM FAQ. > > > > > > No, it's not good at all. > > > > So, what do we do about this? A possible solution is to ungrab cursor > > before some commands (Wait) and then grab again. If there is no solution, > > I think we should disable this commit, because it is problematic. I run a > > version with this commit disabled during a week now, so I may do it. > > I have been thinking about this a lot. The main problem is the > way 'Wait' is implemented at all. The man page claims that fvwm > stays fully functional during a wait which has not been true for a > long time. The wait function implements its own inferior version > of the event loop which will fail in a lot of cases. For example > it does not handle the module queue properly, so modules are not > able to issue commands during a wait. Furthermore it expects that > DispatchEvent() never handles more than one event. This may be > true for MapNotify at the moment, but if HandleMapNotify() would > ever check for a matching DestroyNotify() in the future, 'Wait' > might miss the MapNotify and hang forever. > > This solution will work, but it's not trivial to implement: > > 1) When 'Wait' is called, it inserts the information about the > window to wait for in a table. > 2) 'Wait' returns immediately. It does not do any event handling. > 3) 'Wait' has a special flag in the function table that tells > execute_function() to return immediately without finishing > the function. Instead it builds a new function with the rest > of the actions that would have to be taken as soon as the > window appears. Then it returns and tells the function from > which it was called to do the same. > 4) Finally, function execution ends with a more or less long list > of pending commands. The cursor is ungrabbed and fvwm resumes > execution in the normal event loop. > 5) Whenever a new window is mapped, fvwm checks the list of > pending waits for a matching window. For the first matching > window it executes the recorded function and deletes it after > execution. > > There are still some problems in this solution that would have to > be solved: > > a) How can ctrl-alt-escape be implemented? > b) How can the busy cursor be implemented? > c) What happens to function parameters? When leaving the current > function they have to be recorded in some way. One way would > be to store them in the recorded function somehow (new > command?) Alternatively the commands could be executed as > usual but instead of executing them the string that would have > been executed is recorded.
Dominik, do you work on this now? I think this is a good solution, but it requires so many changes in several places that we may need 2.3.33. Can we restore the previous behaviour of Wait in "I" functions now and release 2.4.0? And this solution may be implemented in 2.4.1 or similar. I think we don't need to fork to 2.5.0/2.9.0 (which is going to be incompatible) immediately after 2.4.0, this may be done later in 2.4.x. Regards, Mikhael. -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
