On Fri, May 18, 2001 at 06:01:03PM +0000, Mikhael Goikhman wrote:
> On 10 May 2001 12:35:27 +0200, Dominik Vogt wrote:
> >
> > On Wed, May 09, 2001 at 11:12:26PM +0000, Mikhael Goikhman wrote:
> > > On 09 May 2001 01:48:44 +0200, Dominik Vogt wrote:
> > > >
> > > > On Tue, May 08, 2001 at 09:58:24PM +0000, Mikhael Goikhman wrote:
> > > > > I don't know when this started.
> > > > >
> > > > > AddToFunc TestFunction I Wait "unexisting window"
> > > > > TestFunction
> > > > >
> > > > > Now, click or drag using the mouse anywhere. Woops, mouse is mostly
> > > > > locked. The keyboard works well (did I say something similar before?),
> > > > > so you may quit this mode by pressing Ctrl-Alt-Escape.
> > > >
> > > > That's not really new. This was always the case if the function
> > > > used anything else but 'I'. I don't know what to do about that.
> > > > The pointer must be grabbed during function execution for the
> > > > reasons I explained in the thread with Paul's deiconify problem.
> > >
> > > I think I see this thread and I can't find where is explained why the
> > > cursor grabbing is needed.
> >
> > >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.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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]
