On Tue, May 29, 2001 at 04:04:26PM +0000, Mikhael Goikhman wrote: > On 29 May 2001 17:00:24 +0200, Dominik Vogt wrote: > > > > > Dominik, do you work on this now? I think this is a good solution, but > > > > No, I didn't dare to start this. Of course it would be much > > cleaner to dump backwards compatibility and make the 'Wait' > > command take the name of a function as an argument instead of > > collecting commands when it is called. > > > > > it requires so many changes in several places that we may need 2.3.33. > > > > We'll need a 2.3.33 anyway. > > Ok, but whoever builds it should use "make_fvwmdist.sh -r -M" to ensure we > don't have 2.3.34. > > > > 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. > > > > How about this: > > > > 1) I'll implement a new wait syntax that takes a function name > > to execute with all the stuf necessary to maintain a list of > > waits. Perhaps the id of the new window could even be passed > > into the function. > > 2) The current wait is kept exactly as it is now but we'll ungrab > > the pointer during execution. This will break 'I'-only > > functions in a few cases and will not work well if the pointer > > was grabbed multiple times when the wait was called. > > 3) The paragraph claiming that "Fvwm remains fully functional > > during a wait" is scrapped. It has never been true and will > > never be true with the old syntax. Only the new syntax can do > > this. > > 4) A warning in the conversion tool is added. > > 5) Anybody complaining about this will have to use the new > > syntax. > > 6) Unless someone else comes up with a good idea, the busy cursor > > feature in waits is dropped for now. > > What would be a problem with the busy cursor in the new implementation? > When a total Wait counter is 0 the normal root cursor may be restored.
I thought that the pointer has to be grabbed to change the cursor. This is nonsese, of course. > (2) is needed, but are other items are needed for 2.4.0? If Wait worked > badly in 2.2.x and users didn't complain, maybe this was enough? > We may even add (2.5) Re-set $w or a new variable $m after Wait. I've coded this with little effort. Still, windows can't be destroyed while the function in running, so I added a patch that at least unmaps a window in DestroyWindow() when it can not be destroyed immediately. I hope this does not break someathing else. > If I understand you correctly, the new non-blocking Wait has the syntax: > > Wait "window-name" callback-function Yes, something like this. Perhaps a new name for the command would be better to stress that the syntax has changed radically. For example "WaitForWindow". > If we already do this, I would extend it to: > > Wait "window-name" callback-function [timeout [timeout-function]] > > and EscapeFunc may trigger timeout-function too if the last is defined. I think this would be a bit cleaner: Wait [timeout <secs>] [timeoutcommand command] command window-name > I have no problem if this new syntax is implemented after 2.4.0. > but I will support your decision. The 'fix' works for me at the moment, so the final solution can wait. If too many people complain we may have to provide the new syntax soon after 2.4. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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]
